In my opinion this is not ready for prime time. Basically: it's inconsistent with the requirements part of RFC 2026 and inconsistent with RFC 2119. I don't think we should create confusion by such inconsistency. There are three main aspects of this inconsistency: 1. "3.1. MANDATORY This is the strongest requirement and for an implementation to ignore it there MUST be a valid and serious reason." That is in effect the meaning of SHOULD as defined in RFC 2119: "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." There is no way we can reasonably equate MANDATORY as defined in the new draft with SHOULD as defined for the last 13 years (and very widely used by other SDOs; RFC 2119 is, I believe, by far the most widely cited RFC). MANDATORY can only resonably be equated with MUST, which is defined in RFC 2119 thus: "1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification." There is no escape clause. It is quite clear there must be no escape clause for MANDATORY. However, the RFC 2119 adjective that maps MUST is REQUIRED, and that should be used to map MUST into an IANA registry. There's no need to confuse people with a new word. 2. With that fixed, the draft doesn't contain a term equivalent to SHOULD. There's a perfectly good adjective for that in RFC 2119: RECOMMENDED. 3. The draft adds confusion by attempting to map the very dubious terms SHOULD+, MUST- and SHOULD-. These are not defined in our standards process and have been used in a very debatable way (IMHO), both in a handful of IETF documents and elsewhere. I simply cannot see the value of deviating from REQUIRED, RECOMMENDED and OPTIONAL. These are clear, self-defining and widely used words. There is value in adding OBSOLETE and RESERVED for use in IANA registries. There is value in the concept behind the proposed AVAILABLE: "3.7. AVAILABLE This is a value that can be allocated by IANA at any time. Implementations: Implementations SHOULD NOT use these values..." However, the choice of keyword is poor. An outsider seeing that protocol number 143 is AVAILABLE might be delighted to start using it. The current word used by IANA is UNASSIGNED and that is much better. Bottom line, I am completely against this draft in its current form. It will create nothing but confusion. Regards Brian Carpenter On 2010-03-18 06:45, The IESG wrote: > The IESG has received a request from an individual submitter to consider > the following document: > > - 'Definitions for expressing standards requirements in IANA registries.' > <draft-ogud-iana-protocol-maintenance-words-03.txt> as a BCP > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@xxxxxxxx mailing lists by 2010-04-14. Exceptionally, > comments may be sent to iesg@xxxxxxxx instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ogud-iana-protocol-maintenance-words-03.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19259&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf