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

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.

  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?