> 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. Very nicely put, John. I completely agree. And to the extent we have "running code" in this area, I believe it supports this view. > 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: > ... In the specific case of the current proposal, my view is that the reasons the IESG gave for rejecting this proposal put us all out on a very shakey limb, and the added comments about the likely outcome of this work being made an IETF work item of some sort have no limb at all underneath them. I also have another concern here that I don't believe anyone else has mentioned. In response to criticism of the lack of openness of the process used to arrive at this rejection, it has been asserted that it had to be this way due to the lack of availability of a specification for review. As many of you no doubt know, I have long been an advocate of having freely available specifications whenever possible. I have frequently pushed back on IETF that involves references to outside work that isn't readily available. These concerns have usually been dismissed with responses like: "There's no rule against it" or "The specification is available to those who really care" or "There's nothing we can do to improve the situation so live with it". And in fact we have numerous specifications which depend on such references. In fact while I was on the IESG on at least one occasion I paid $ in order to obtain a specification I felt I needed in order to carry out proper review of something. After all this I find it quite curious to see the lack of a publicly available specification used to justify the way this was handled, when in so many other cases we simply shrugged and moved on. Even worse, the fact of the matter is the specification is publicly available: http://www.packet.cc/IPv6Q-IETF-2A.htm No googling necessary; this URL was included in the original submission request. Now, the request also stated that this is not the final form of the specification that was submitted to the ITU. But it seems very unlikely that the specification has changed sufficiently that the earlier, publicly available draft couldn't be used for review purposes. But rather than speculate on that, since we have the author of the proposal here, I'll just ask a direct question. Dr. Roberts, do you believe there have been sufficient changes between the version posted at the above URL and the ITU submission that it isn't reasonable to decide things based on the public version? And if there have in fact been sufficient changes, would it be possible to make a version with those changes available for public review? > > > 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. Agreed again. I'm looking forward to seeing your document. Ned _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf