At 12:25 PM -0700 6/12/07, Thomas Narten wrote:
Some general comments on this thread. I understand the argument that
some make that we should just give out code points in all cases,
because otherwise we invite squatting.
That is one reason to give out code points liberally, but not the
only one. The reason that both John Klensin and I gave (and I think
Dave Crocker echoed) is that giving out code points liberally
increases interoperability. It gives developers stronger confidence
that the registry is both correct (no overlapping values due to
registration race conditions gated on RFC publication) and complete
(no squatting).
On the other hand, I do believe
that withholding code points does prevent (in some, but not all cases)
use of extensions that are potentially problematical. As one concrete
example, other SDOs are generally hesitant to endorse/use protocols
that have not been properly granted code points. This has been a
carrot/stick in the past to get those SDOs to come to the IETF with
the work rather than just having them "embrace and extend" our
protocols.
Doing so inherently causes lack of interoperability during the
carrot-stick dance, and often for a long time after the dance is
over. That probably helps the IETF leadership but hurts developers of
our protocols.
Do you think this is not useful/necessary or that it can be
done in other ways?
It is probably not necessary but it is probalby useful nonetheless. A
different way to achieve the carrot-stick goal might be to use the
registry to list the IETF's perceived soundness of the codepoint's
registration. "Stanards-track RFC", "Informational RFC", "Outside
spec; see <URL>", "Outside spec; believed to be unstable by the IESG
on mm/dd/yy", "Outside spec; believed to have serious technical
issues; see <http://www.iesg.org/comments/nnnn>", and so on.
Also, if one thinks that code points should just be given out in all
cases, how do we deal with stuff like RFC 3427?
That's a straw-man; no one on this thread said "in all cases". There
are at least two cases where liberal registration are not good:
- A limited-size namespace (usually protocols written pre-1995)
- A namespace where the names have significant semantic value
("microsoft", "better-auth", ...)
And, does this also mean, for example, that anyone should be granted
ICMP code points?
Are you really calling for essentially granting code points to anyone
who asks?
No. In order to achieve interoperability, stable documentation of the
definition of the codepoint should always be required. Additional
commentary from the IESG and/or IAB might also be useful.
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf