Eliot,
There are at least two things that are wrong with the model you
describe below,...
(1) The assignment of address space, and the whole
notion of private networks with specialized space, are
not "just options" to a protocol, regardless of whatever
else they may be or may have been.
(2) RFC 1597 was fairly extensively discussed within the
IESG and, if I recall, on the IETF list. Its
substantially equivalent successor, RFC 1918, was Last
Called in the IETF and approved as a BCP document.
Not exactly protocol options that can be ignored (or the packets
or messages disposed of) if one doesn't want to utilize them.
Even the part you don't want to reopen (and I don't either) is
not a consequence of the address allocation, it is the result of
a _recommendation_ (real or imagined) by the IETF community (and
the RIRs) that private address space be used in certain
circumstances. So, while I disagree that a decision to allocate
address space in a particular way is similar to allocating an
option number, the decision that needed careful community review
and appropriate recommendations was the protocol --and, in the
case you cite-- the idea of private address space. Without the
protocol notions, the space allocations would have had little
effect.
john
--On Tuesday, June 28, 2005 20:13 +0200 Eliot Lear
<lear(_at_)cisco(_dot_)com> wrote:
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf