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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf