Date: Tue, 28 Jun 2005 20:13:20 +0200
From: Eliot Lear <lear(_at_)cisco(_dot_)com>
Message-ID: <42C19340(_dot_)8000802(_at_)cisco(_dot_)com>
| 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.
They'e not options. There's no question but that different parameters
(different parameter kinds) should be (able to be) treated differently.
| Jon Postel's decision absent community review (and it was absent)
I certainly recall no discussion about the values assigned, but I do
recall plenty of discussion about the need to assign address space for
disconnected sites (which was the intention of those) to avoid everyone
using 192.9.200/24 (or any other random number they assigned themselves,
I know that the first IP number I used was 55/8 - seemed like a good choice
to me at the time!) Whether that discussion amounted to consensus or not
I wouldn't like to say after all of this time, but it certainly occurred.
| had a profound impact on the Internet architecture.
It probbaly did, it has (by accident, rather than design) kept the
net operating. Withough that (and NAT really) the internet would
be dead (replaced by something else, or perhaps, nothing else).
In the early days, it certainly actied as intended, many disconnected
sites used those numbers rather than self-selected values.
| What happens if intervening devices implement it?
And, I presume you mean, people actually send packets containing the option.
Then, either it does useful things (for someone), or it does not. In the
former case, the option remains, and whether you, or I, like the
effects produced, someone clearly would have to. And if they're getting
a benefit, they are going to do that, whether blessed or not, registered
or not (just consider the amount of rewriting the v4 TOS byte that happened,
long before anyone considered blessing that practice) If it doesn't work,
or no-one likes it, then it gets disabled (the vendor who added it
gets pressure to at least make processing the option optional, and it
is disabled).
While I'd sure like the net to return to a place where it can be carefully
architected to meet good standards of purity and virtue, those days are
long gone - there are all kinds of evil things happening out there, many
of them not documented anywhere.
Much better in my opinion to at least have some idea what is happening,
so we can find ways to work around any badness that appears, than to
be faced with unknown mystery that is simply used with no explanation.
| 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.
Bob may be talking about it, but I don't really see it happening.
That functionality is required by too many existing users (the
Router Alert option wasn't invented for no purpose at all...)
kre
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf