--On Sunday, 26 June, 2005 09:28 -0700 Allison Mankin <mankin@xxxxxxx> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf