Rob,
| is whether the proposed mechanism will interfere
| with existing or other proposed mechanisms.
This is totally irrelevant. We're talking about an option. Options,
by their very nature are optional. If use of an option interferes
with some other processing that you require, then you simply don't use
the option.
Let's look at an analogy that worked just as you suggest: the assignment
of 10/8 172.16/16 and 192.168/16 in RFC 1597. Jon Postel's decision
absent community review (and it was absent) had a profound impact on the
Internet architecture. Now we can argue till the cows come home as to
whether that impact was good or bad [I really am over it! ;-], people
will agree that we live with the results today and will continue to do
so for years to come. I claimed at the time and still believe that
Jon's actions were reckless and the IAB was wrong to not at least review
the allocation request.
Your argument that "it's just an option" doesn't wash with me not so
much because intervening devices will have to ignore it but quite the
opposite. What happens if intervening devices implement it? Had nobody
made use of Network 10 the debates wouldn't rage on till this day. If
people make use of Dr. Roberts' work where it provides some marginal
value to some subset of the community but at the expense of the rest of
us, what do we do then to repair the damage?
And so with respect to the following:
The only potential cost here is the loss of an option code value,
until such time as this option is certified extinct (assuming that
it fails of course, if it succeeds, then the option would be
in active use, and no-one would want to reclaim it).
I would disagree for the same reasons. I care more about what happens
if the thing gets used and causes a bad interaction. I don't see us
getting into a situation of having to implement the equivalent of the
telnet EXOPL given that Bob is talking about deprecating hop-by-hop
altogether.
In this case, I can't say whether or not there will be bad interactions,
but clearly the IESG is very concerned.
Eliot
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf