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(_at_)ietf(_dot_)org mailing lists by 2010-04-14. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf