Date: Mon, 27 Jun 2005 17:00:22 +0200
From: Brian E Carpenter <brc(_at_)zurich(_dot_)ibm(_dot_)com>
Message-ID: <42C01486(_dot_)1050302(_at_)zurich(_dot_)ibm(_dot_)com>
| The debate (except that since the work hadn't been brought to the IETF,
| the debate hasn't happened)
Except that it has been reported that the work was given to the IETF
(via an IETF WG) but the debate still didn't happen...
| 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.
How that that concept possibly be confusing?
| It isn't about the option number in itself
Of course not, since, once given approval to do so, IANA would
actually be picking the number to be assigned, not the IESG, IETF,
or anyone else (in this particular case, sometimes for some good reason
IANA is instructed to register a particular number - that isn't what
is happening here).
| (apart from the normal need for careful stewardship of all finite
| numbering spaces).
Not relevant here - this particular numbering space is essentially
unused, and there's no particular reason to assume that is going
to change any time soon. What's more, if it does, there's no reason
the number space needs to remain finite - if it ever looked likely to
(even potentially) be exhausted, developing a backwards compatible
extension mechanism would be trivial. There's no question at all that
it can be done - the only questions are whether it needs to be (whether
the number space has any chance of being exhausted) an then which of
several possible extension methods would be best to choose.
kre
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf