Thomas,
Sorry for the delay in responding to this. I think you have
misunderstood my position (although maybe not the position of
others). See below.
--On Tuesday, 12 June, 2007 12:25 -0700 Thomas Narten
<narten(_at_)us(_dot_)ibm(_dot_)com> wrote:
...
And that last clause -- i.e., the fact that document has not
progressed in three years or more -- may suggest either that
(i) if modifying it is the most constructive way forward, we
have a problem or (ii) that it is not an effective way
forward, whether or not it is constructive.
IMO, completing this document is long overdue. It is a
tremendous improvement over 2434.
Indeed.
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. 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. Do you think this is not
useful/necessary or that it can be done in other ways?
I have never advocated "just give out code points in all cases".
I think requirements for good documentation and evidence of
interest that extends significantly beyond the proposers are
quite reasonable. I agree with the comments in 2434bis about
the problems with unreviewed extensions and code point requests.
I think your SDO case could be dealt with by requirements on the
document and for IETF review of the documentation. I recognize
that we have gotten ourselves into some situations where there
is code point scarcity and believe that we need to deal with
them with some finesse. And, while I believe that there are
usually better ways to deal with those cases, I wouldn't lose
any sleep over withholding a code point for an idea that the
IETF community had concluded was likely to be harmful (note
"IETF community...concluded", not just "one reviewer thought it
was a bad, unnecessary, or even redundant idea"... even if that
reviewer is an AD).
Where I think we go astray is when we say "the IETF has to reach
consensus that it _likes_ a particular idea in order to get a
code point". We also go astray when we use a combination of
procedures to turn a code point registration requirement for
"RFC publication" into a requirement for enthusiastic IESG
approval. Interoperability considerations suggest that, if
something is going to actually be out there, the community
benefits by as much knowledge of it as possible. Holding up a
code point to get good documentation that contributes to that
knowledge is reasonable. Asking for evidence that the thing
will actually be deployed in ways that might interact with other
uses of the registry is reasonable. Trying to block deployment
by refusing to allocate a code point is a bad idea because it
won't work and will cause people to ignore our registries.
In the light of this discussion, the problem with 4243bis is
that it is fairly neutral in Section 4.1 wrt the various
statements/ requirements that can be imposed on a registry. I
now believe that any registry provision that requires someone to
agree to the idea of assigning a codepoint --not just to agree
that, e.g., documentation is adequate such as with the
"Specification required" category-- should require significant
justification in the registry proposal for the additional
restrictions. I think 4243bis should make that requirement and
that it should contain text that indicates that "RFC Required",
"IETF Review", "Standards Action", and "IESG Approval" are all
exceptional cases that require convincing the community that
interoperability and other important values are well served by
the relevant body being able to deny code point assignment by
failure to act affirmatively.
Of course, if there are provisions for private or alternate
assignments that can be used by parties who do not achieve
strong levels of approval without constraining the ability of
their protocols to work, those strong levels of approval may
rationally be applied to the the more restricted assignment
cases.
Also, if one thinks that code points should just be given out
in all cases, how do we deal with stuff like RFC 3427?
And, does this also mean, for example, that anyone should be
granted ICMP code points?
I think these are largely red herrings, for the reasons outlined
above. However, I think it is generally unwise to try to use
control of code point assignments as a means of retaining IETF
control over a protocol. We need better ways, if only because
taking the code point route encourages code-squatting and
undocumented extensions, neither of which are, in general, in
the best interest of the Internet. I also believe that we
should, in the future, be very cautious about creating new
protocols or registries that narrowly constrain the code point
space.
Are you really calling for essentially granting code points to
anyone who asks? (That is what I hear when the bottom line is
that the IETF can't say no, because, the reality is (IMO) that
some only come to the IETF because they have to. They'd just
as soon do their own thing and don't appreciate having their
proposals get seriously reviewed.)
Again, I think there is a huge difference between requiring good
documentation and serious review and requiring that the IETF
community (or the IESG, or specific ADs) _like_ a particular
idea. If there are parties whom one wants to try to force into
serious review, then let's focus on that: require documentation,
require an opportunity for review, require that the parties
respond clearly and openly to review comments. But, unless
there are very special circumstances, don't refuse to allocate
code points because we don't like an idea.
Put differently,
* It is reasonable for the IETF to say "no because you
don't have documentation adequate to determine what this
code point identifies".
* It is reasonable for the IETF to say "no because you
have not participated in a review process in good faith"
* It _may_ be reasonable for the IETF to say "no because
you don't intend the protocol to be used on the public
Internet and therefore you don't need a code point"
* It is reasonable for the IETF to say "no because there
is clear evidence, which we are willing to document in a
public way that your idea, or assignment of a code point
to it, will be harmful to the Internet if used as
intended"
* It is not reasonable for the IETF to say "no because
some of us think your idea stinks" or "no because we
don't like elements of your business model or your IPR
entanglements".
With regard to the exception/ override language of 5.3, I think
it is extremely useful, but doesn't have much to do with this
issue as I see it. Yes, it could be used to fix a code point
for draft-housley-tls-authz-extns if the IESG thought that
appropriate, just as Harald's "one-line document" kludge would.
But the real issue here, as I see it, isn't having a mechanism
for making better exceptions, it is cleaning up our acts about
what we expect and require.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf