Definitions for expressing standards requirements in IANA registries.
draft-ogud-iana-protocol-maintenance-words-03

[Ballot discuss]
I don't believe this document solves the problem it sets out to
  address, which seems to be that we have a bunch of protocols that have
  optional components, and in order to understand what components one
  MUST, SHOULD or MAY implement, one has to read the set of RFCs and
  figure this out. That takes some effort. The intent here appears to be
  to include this information in the IANA registry that holds codepoints
  associated with the various options, and it defines some terms that
  summarize the implementation requirements of specific options. I have
  some serious concerns about this proposal. First, on order to
  implement a protocol, one needs to read the various RFCs anyway. So
  this saves no effort for implementors. Second, even if this is
  intended to create an overview of what's in the RFCs, there is the
  danger that it may become inconsistent with the RFC text over time
  (especially with the auto-modification instructions in Section 4.)
  Third, for this to be at all useful and not confusing, the existing
  registries would need to be converted, which is practically
  impossible. Fourth, protocols whose extensibility mechanism isn't
  coupled to an IANA registry (e.g., ones that assign new bits by
  publishing RFCs that update the base spec) aren't covered by this
  proposal.

  Because of these high-level reasons and the more detailed ones below
  I believe it would be harmful to publish this document in its current form.

  I fully understand that this isn't an actionable DISCUSS at this point.
  I'm entering it for the purposes of starting a discussion and will
  revise it as we do this, and may move to abstain eventually.

Section 1., paragraph 2:
>    This document is motivated by the experiences of the editors in
>    trying to maintain registries for DNS and DNSSEC.  For example, DNS
>    defines a registry for hash algorithms used for a message
>    authentication scheme called TSIG [RFC2845], the first entry in that
>    registry was for HMAC-MD5.  The DNSEXT working group decided to try
>    to decrease the number of algorithms listed in the registry and add a
>    column to the registry listing the requirements level for each one.
>    Upon reading that HMAC-MD5 was tagged as "OBSOLETE" a firestorm
>    started.  It was interpreted as the DNS community making a statement
>    on the status of HMAC-MD5 for all uses.  While the document was
>    definitely overreaching in its specification, the point remained
>    there was no standard way to tag different requirements levels in
>    protocol registries.

  I don't see how this document addresses the problem you saw with
  DNSSEC. Surely people would *still* have confused a specific statement
  about one registry vs. a general statement. (Having an RFC to which
  you could have pointed for a definition of OBSOLETE would not have
  changed that.)


Section 1., paragraph 3:
>    In the security community there has been some attempts to indicate
>    emerging and retiring algorithms by adding + or - to RFC 2119 words
>    RFC 4835 [RFC4835], SHOULD+ is to be interpreted as "SHOULD for now,
>    expected to be MUST soon".  MUST- indicates that the currently
>    required algorithm or feature might be retired sometime in the near
>    future.  This has traditionally been accomplished by adding a
>    terminology section to each document.  A now expired draft
>    (draft-hoffman-additional-key-words) attempted to establish these
>    additions as new keywords but was never fully adopted.  This document
>    attempts to revive this effort.  This document adds to and updates
>    the labels defined in RFC 5226 [RFC5226] as well.

  The RFC2119 keywords and the RFC5226 labels have *very* different
  purposes. Simply saying that this document adds to them both is
  extremely confusing unless you are *very* clear what you mean. For
  example, can I use DISCOURAGED or MANDATORY in an RFC when I don't
  talk about IANA registries? WHat would that mean?


Section 3.1., paragraph 1:
>    MANDATORY
>    This is the strongest requirement and for an implementation to ignore
>    it there MUST be a valid and serious reason.

  Either something is mandatory or it isn't. If I don't implement it,
  I'm not implementing the spec, whether I have a "valid and serious
  reason" for this or not.


Section 3.1., paragraph 2:
>    Note 2:  The requirement applies only to new or future
>      implementations on the day the requirement is released.  In many
>      cases existing implementations can become compliant via software
>      upgrade or point release.

  That means that IANA needs to record the date when something took
  effect.


Section 3.2., paragraph 1:
>    Implementations:  Any implementation MAY or MAY NOT support this

  MAY NOT is not an RFC2119 term. Please rephrase.


Section 3.3., paragraph 1:
>    Note:  This is the most dangerous term of the requirements words as
>      it is easy to read too much into this term.  The intent is to
>      express the following:
>      *  This functionality is not needed/desired anymore by the given
>          protocol.  This is not to say that this particular
>          functionality should be obsoleted by other protocols that use
>          the same (or similar) functionality.

  I believe the intent you state here is too much influenced by the
  specific DNSSEC example and isn't general.


Section 3.4., paragraph 1:
>    Operations:  This functionality SHOULD NOT be immediately deployed as
>      part of normal operations.  This functionality SHOULD be tested in
>      a controlled environment to measure the quality and readiness of
>      the functionality and gain operational experience.  Operators can
>      expect functionality marked ENCOURAGED to become MANDATORY at some
>      point in the future unless a significant problem is encountered
>      during early deployments.

  Saying that something marked ENCOURAGED should not immediately be
  deployed is confusing (encouraged means "do this"), but it is also
  going to far. Clearly there have been cases where we absolutely want a
  new function to be deployed immediately.


Section 3.6., paragraph 1:
>    Implementations:  Implementations MUST NOT use any RESERVED values
>      for implementation specific processing.

  They must not use them at all, no?


Section 3.7., paragraph 1:
>    Implementations:  Implementations SHOULD NOT use these values for
>      implementation specific processing.

  They must not use them at all. Saying "should not" here gives
  permission for squatting.


Section 4., paragraph 1:
>    In theory the process to change the status of a protocol field should
>    be the same as reserving a new field.  In practice this is going to
>    be burdensome, as there is a chance the IESG will have to process
>    many documents that are simply saying "Value X in Registry Y is now
>    Mandatory" (or similar).

  Those RFCs are quick to process, because the only action in them are
  for IANA. I don't see this as a huge overhead, especially because
  registries don't change all that often.


Section 5., paragraph 3:

>    +--------+-------------+-------------------------+------------------+
>    | Value  | Algorithm  | Requirement            | References      |
>    |        | name        |                        |                  |
>    +--------+-------------+-------------------------+------------------+
>    | 0      |            | RESERVED                | RFCFOO          |
>    | 1      | ROT-13      | OBSOLETE                | RFCFOO, RFCrot13 |
>    | 2      | DES        | DISCOURAGED            | RFCFOO, RFCdes  |
>    | 3      | BlowFish    | MANDATORY              | RFCblowfish,    |
>    |        |            |                        | RFCrot13        |
>    | 4      |            | RESERVED until 2022    | RFCrot13        |
>    | 5      | AES        | Encouraged              | RFCFOOaes        |
>    | 6      | Enigma      | DISCOURAGED, OBSOLETE  | RFCFOO,          |
>    |        |            | in Jan 2012            | RFC-Enigma      |
>    | 7 -    |            | Available              | RFCFOO          |
>    | 255    |            |                        |                  |
>    +--------+-------------+-------------------------+------------------+

  DISCOURAGED, OBSOLETE is confusing. Are DIS/ENCOURAGED modifiers on
  other keywords or standalone keywords in their own right?

[Ballot comment]
>4.  Protocol Registry Maintenance
>
>  In theory the process to change the status of a protocol field should
>  be the same as reserving a new field.

I would note that several protocols specified separate IANA procedure for updating status of a protocol field, such as marking something as OBSOLETE.

>  In practice this is going to
>  be burdensome, as there is a chance the IESG will have to process
>  many documents that are simply saying "Value X in Registry Y is now
>  Mandatory" (or similar).

[Ballot discuss]
I am generally in favour of this document going forward. However I have a small set of issues I would like to discuss before recommending approval of this document:

1)
>3.7.  AVAILABLE
>
>  This is a value that can be allocated by IANA at any time.
>  Implementations:  Implementations SHOULD NOT use these values for
>      implementation specific processing.
>  Operations:  Any implementation claiming to know the meaning of this
>      unallocated code MUST NOT be used.

I don't find the description of this value to be very clear. What is the use case?

2)

5.  Example registry

  This is an example registry for an example protocol FOO that uses an
  encrypted channel for messages.  The algorithms listed here are only
  for illustration uses.

                                    FOO

  +--------+-------------+-------------------------+------------------+
  | Value  | Algorithm  | Requirement            | References      |
  |        | name        |                        |                  |
  +--------+-------------+-------------------------+------------------+
  | 0      |            | RESERVED                | RFCFOO          |
  | 1      | ROT-13      | OBSOLETE                | RFCFOO, RFCrot13 |
  | 2      | DES        | DISCOURAGED            | RFCFOO, RFCdes  |
  | 3      | BlowFish    | MANDATORY              | RFCblowfish,    |
  |        |            |                        | RFCrot13        |
  | 4      |            | RESERVED until 2022    | RFCrot13        |
  | 5      | AES        | Encouraged              | RFCFOOaes        |
  | 6      | Enigma      | DISCOURAGED, OBSOLETE  | RFCFOO,          |
  |        |            | in Jan 2012            | RFC-Enigma      |
  | 7 -    |            | Available              | RFCFOO          |

Sorry for nitpicking, but after reading the document I assume that only the uppercased values have the specified meaning. If that is the case,
then you need to change Encouraged and Available to ENCOURAGED and AVAILABLE respectively.

  | 255    |            |                        |                  |
  +--------+-------------+-------------------------+------------------+

3) Holding DISCUSS on IANA's issues:

IANA has questions about this document.

IANA does not understand the implications of the IANA Actions requested.
Specifically, what are the implications for existing
registries? We understand that the defined terms in the document could
be added to future registries based on requests of future document
authors. However, IANA does not have a mechanism for timed modifications
to registries. It is unclear to IANA whether or not this is intended to
be mandatory for future registries. In the event that the addition of
these terms is mandatory, IANA expects that there will be additional
workload associated with the creation of new registries.

IANA's experience in classifying parameters varies from registry to
registry, and we are concerned that a common set of definitions might be
difficult to apply across all new registries.

The dynamic reservation mechanism discussed in section 4 is of
particular concern, as IANA has no currently deployed mechanism for
timed changes to a registry.

The imposition of flag days in registries seems to IANA to be a bad
precedent.

--------------------------

So basically there are 2 issues here: applicability of this to old and new registries. I think Opt-in is required in both cases.

The second IANA issue is about timed updates. While I agree this might be extra load for IANA, I think the community can help IANA with tools. For example a web calendar with email reminder capability can be used for that.

[Ballot comment]
>4.  Protocol Registry Maintenance
>
>  In theory the process to change the status of a protocol field should
>  be the same as reserving a new field.

I would note that several protocols specified separate IANA procedure for updating status of a protocol field, such as marking something as OBSOLETE.

>  In practice this is going to
>  be burdensome, as there is a chance the IESG will have to process
>  many documents that are simply saying "Value X in Registry Y is now
>  Mandatory" (or similar).

[Ballot discuss]
I am generally in favour of this document going forward. However I have a small set of issues I would like to discuss before recommending approval of this document:

1)
>3.7.  AVAILABLE
>
>  This is a value that can be allocated by IANA at any time.
>  Implementations:  Implementations SHOULD NOT use these values for
>      implementation specific processing.
>  Operations:  Any implementation claiming to know the meaning of this
>      unallocated code MUST NOT be used.

I don't find the description of this value to be very clear. What is the use case?

2)

5.  Example registry

  This is an example registry for an example protocol FOO that uses an
  encrypted channel for messages.  The algorithms listed here are only
  for illustration uses.

                                    FOO

  +--------+-------------+-------------------------+------------------+
  | Value  | Algorithm  | Requirement            | References      |
  |        | name        |                        |                  |
  +--------+-------------+-------------------------+------------------+
  | 0      |            | RESERVED                | RFCFOO          |
  | 1      | ROT-13      | OBSOLETE                | RFCFOO, RFCrot13 |
  | 2      | DES        | DISCOURAGED            | RFCFOO, RFCdes  |
  | 3      | BlowFish    | MANDATORY              | RFCblowfish,    |
  |        |            |                        | RFCrot13        |
  | 4      |            | RESERVED until 2022    | RFCrot13        |
  | 5      | AES        | Encouraged              | RFCFOOaes        |
  | 6      | Enigma      | DISCOURAGED, OBSOLETE  | RFCFOO,          |
  |        |            | in Jan 2012            | RFC-Enigma      |
  | 7 -    |            | Available              | RFCFOO          |

Sorry for nitpicking, but after reading the document I assume that only the uppercased values have the specified meaning. If that is the case,
then you need to change Encouraged and Available to ENCOURAGED and AVAILABLE respectively.

  | 255    |            |                        |                  |
  +--------+-------------+-------------------------+------------------+

IANA has questions about this document.

IANA does not understand the implications of the IANA Actions requested.
Specifically, what are the implications for existing
registries? We understand that the defined terms in the document could
be added to future registries based on requests of future document
authors. However, IANA does not have a mechanism for timed modifications
to registries. It is unclear to IANA whether or not this is intended to
be mandatory for future registries. In the event that the addition of
these terms is mandatory, IANA expects that there will be additional
workload associated with the creation of new registries.

IANA's experience in classifying parameters varies from registry to
registry, and we are concerned that a common set of definitions might be
difficult to apply across all new registries.

The dynamic reservation mechanism discussed in section 4 is of
particular concern, as IANA has no currently deployed mechanism for
timed changes to a registry.

The imposition of flag days in registries seems to IANA to be a bad
precedent.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Olafur Gudmundsson is the Document Shepherd for
draft-ogud-iana-protocol-maintenance-words-01.txt

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document has got some review, this is not a product of a WG
thus the document needs a IETF review.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

May need more review from security community; one of the target audiences
of this draft. The document needs review from IANA as this will impact
their operations. The document needs review from the operational community that the approach suggested for separation of requirements
between implementations and operations is clear enough and can fit into
operational environments.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

Due to the lack of review it is hard to say.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

N/A:  This draft is not the product of a working group.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

The authors are not aware of any conflicts.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

Yes.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

Yes, it has an IANA considerations section.  There are no specific
actions required by IANA from this draft.  It is a guide for future draft
authors to include qualified statements about IANA registry entries that
may include status information.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

Yes, but there are no formal code in the draft besides the XML of the
document itself.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

      Technical Summary

        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.


RFC 2119 defines words that are used in IETF standards documents to
indicate standards compliance.  These words are fine for defining new
protocols, but there are certain deficiencies in using them when it
comes to protocol maintainability.  Protocols are maintained by
either updating the core specifications or via changes in protocol
registries.

This document proposes standard terms to use in protocol registries
and possibly in standards track documents to indicate the life cycle
support of protocol features and operations.

      Working Group Summary

        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

N/A.  The document is not the product of a working group.

      Document Quality

        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

The document does not specify a new protocol.  The document may need some
socializing to get the new defined terms into common usage.