--On Sunday, 26 June, 2005 09:28 -0700 Allison Mankin
<mankin(_at_)psg(_dot_)com> wrote:
Hi, John,
There are two different IETF IANA registry goals (at least):
- maintenance of protocol parameters by the IANA for
keeping the namespace free of conflict
- policy for the extension of an IETF protocol, which
is expressed by the rules governing the
issuing of new codepoints for particular elements
in that protocol.
In the message the IESG sent about Roberts' request,
we pointed out that the IPv6 Hop by Hop option extensibility
is governed by a BCP, RFC 2780, which requires an IETF document
(standards track or other), or in a fallback, IESG review.
This is the action the IESG has taken.
Your message about the the registries being largely for
prevention of conflicts and so on is true for some registries,
but for many others there's an extension policy in place too.
For many protocols, there's an RFC that states a requirements
for some or all the codepoints for an IETF docoument before
IANA allocations. You can see these requirements in the IANA
pages now. These requirements reflect views by the developers
that the protocol needed engineered coherency, an IETF review
process that would ensure architectural considerations when
the extensions are made.
(The IETF is here for engineering the protocols, after all).
Allison, I'm generally supportive of that view. I've actually
been responsible for writing some of those IANA considerations
sections that require standards-track actions. In the light of
this situation and a few recent other ones, I have modified my
historical view somewhat and would encourage the IESG to do some
similar rethinking.
Let's consider two cases. In one case, the IETF finds an idea
aesthetically unattractive. The community concludes that, were
the IETF to try doing some work in the area covered by the
proposal, we could do a better job... and, perhaps, someday, we
might. But registering the option cannot be demonstrated to
cause a significant interoperability threat: at worst the
associated protocol extension is just dumb. In the second case,
the nature of the protocol and extension mechanism involved is
such that a proposed extension actually would cause an
interoperability threat or we can demonstrate that the proposed
extension would simply not work. For the second case, it is
probably reasonable to say "no registration". I suggest that,
while the number of instances of that case is certainly not
zero, it should be small and that it should be a design goal for
us to minimize them: in a way, having a situation in which an
unapproved extension can break a protocol violates much of what
we claim to know and believe about robustness.
But, for the first, I'm getting more and more anxious about
rejecting a registration request. That is largely because, if
the applicant still feels that the idea is a good one, we've got
lots of unfortunate experience that he or she will just ignore
the registration requirement, squat on a code, and proceed as if
the allocation had been made. Worse, that applicant may not come
back and ask the next time, depriving the community of a
heads-up and the applicant of potentially-valuable IETF review.
I've said part of this in an earlier note but I think we've got
to get past what I've come to think of as considering the IETF
as some sort of Protocol Legislature that makes Protocol Laws
with the assumption that people will follow those laws or the
Protocol Police will show up and drag them off for punishment.
We make voluntary standards. Those standards are followed or
not based on our powers of persuasion that there is community
support for them and that the community support is meaningful
because it results from adequate review, conclusions based on
that review, and persuasive documentation. Reliance on
authority-assertions is a bad idea, not only because no one
individual or group can claim such authority by right, but
because the Protocol Police aren't out there to enforce the
authority. If someone can ignore our conclusion that an idea
is dumb and go ahead and deploy it anyway, we gain nothing and
create risks by not assigning an option number to the dumb idea
-- risks that are primarily the consequence of not being able to
tell in practice what options are being used.
So I now believe that we should have provision in some of those
registries for notes that say "The IETF has concluded that the
option or extension represented by this value is a really rotten
idea. Explanation in RFC NNNN (or the IESG note at <URL>)".
That would be a good move because it would give potential users
of the option an easily-accessible indication that they should
consider the issues raised carefully before deciding to deploy
the option. Denying the registration, except in the
second case above, may turn into a foolish and unnecessary
threat to interoperability.
To state that somewhat differently, since we cannot effectively
prohibit the deployment of an extension or option of which the
IETF disapproves, the best things we can do for the Internet are
make it as easy as possible to identify the use of the extension
so it can be effectively quarantined and to make information
about why we consider it a bad idea readily available.
Ironically, both of those goals are most strongly aided by
registering the extension and assigning an appropriate
identifier, rather than rejecting registration requests and
hoping the idea goes away.
While the situation with the Hop-by-hop proposal appears closer
to the first group of cases than the second, it appears to me to
be
complicated by two other factors:
(i) Apparently, this registration request represents work being
carried on in other standards bodies and we have a
presumably-good liaison relationship with one of them. The IESG
should, I believe, consider whether Dr. Roberts should be
encouraged to discuss this proposal further with them, whether
we should have a WG-level dialogue open with them about the
appropriateness of the protocol design, and, if a registration
request is made, whether that should come across the liaison
channel as a registration request in support of _their_
protocol. At one level, that sequence would be nothing more
than a procedural nicety. But at another, if this is a
standards body whom we recognize and which recognizes us, our
failure to make option numbers available for protocol extensions
which we dislike but can't talk them out of on technical grounds
could rapidly lead the Internet to competing and conflicting
registries for the same protocol parameters. That isn't good
in the address space; it is much less good in these name spaces.
(ii) For the reasons above and in my earlier note, I think the
IESG, and the IETF more broadly, must exert great caution in
rejecting a registration request and must exert that caution in
public. For example, the language of 2434, and the language of
2780 with regard to the registry in question, indicates that the
IESG may approve one of these requests. They do not appear to
me to indicate that the IESG may definitively reject it. It
would be perfectly reasonable, IMO, for the IESG to say "You
requested that we exercise our discretion and register this.
After reviewing it, we believe that the protocol option itself
will be controversial in the community and that it needs
significantly more review and discussion, either to refine it or
to adequately clarify and document the reasons why it may be
problematic. So we cannot approve the registration request at
this time but encourage you to open a dialogue with the relevant
WG(s) in the hope that you will be able to find common ground
and convince each other, or at least educate each other."
But, instead, as far as I can tell, the IESG communicated a "go
away and don't come back" message. My knowledge is, of course,
poor because the nature and unfolding of the IESG discussions,
what the applicant was told, and what the IESG intended and
intends are appearing only incrementally, supported by poor
minutes and statements with "may not represent consensus"
disclaimers attached. For a registration request and for the
reasons given, I (and apparently others) believe that "go away
and don't come back" is a message that should be delivered only
with strong indications of IETF community consensus and not
based only on the opinion of the IESG about what they consensus
might be.
Historically, we maintain registries of various protocol
parameters, not to endorse them, but to prevent conflicts in
the meaning/ interpretation of such things. [snip...]
Note there are hundreds of registries! One summary does not
fit all. Also, endorse is a very loaded word. They express
RFC 2434 / BCP 26 policies.
Actually, I think it is possible to state, or restate, guiding
principles, even if the details for those registries are
different. In the interest of focusing discussion, an
Internet-Draft that attempts to do just that will be submitted
for posting later today.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf