[secdir] secdir review/last call comments for : draft-ogud-iana-protocol-maintenance-words

[Sam Hartman <[e-mail]>]

I have been assigned this draft as part of the secdir review process.  I
see no security issues with the draft that are really within the scope
of a secdir review.

I do have significant concerns I'd like to raise as last call comments.

In general, I agree with most of the concerns raised about this draft.
I believe that an applicability statement is the appropriate way to
address what this draft is trying to do.  If you're looking to make a
process change how about writing a simple proposal for allowing IANA
registries to reference applicability statements that describe protocols
they cover.  You might have a note like "For current status of the
implementation requirements for these algorithms in dnssec, se RFC
xyzzy."

The applicability statement could say which registries it links to, and
could remove the links of statements it obsoletes.

I realize that's somewhat going down the path of including unnecessary
information in a registry, but I think it is a reasonable compromise
until/unless something broader like ISDs come along.  Also, by all means
try to put together an ISD-like proposal if you have the energy.  I'm
one of the people who thought that the last ISD proposal was not
sufficiently specified and might run into fundamental problems, but
thought there were some really good ideas there, so if you do go down
that route I'd be happy to share some concerns while remaining
constructive.


Stunningly, given the concerns raised so far, I think I have some new
ones.

First, this draft attempts to establish operational requirements.  The
term operational requirements is not well defined.  In the context of
DNSsec, we can imagine what that might mean: zone operators need to use
one of the mandatory algorithms to sign their zones in order to
guarantee that others can validate it.

Especially for Internet-wide protocols it is often appropriate to have
best-current-practice recommendations for the operational deployment of
those protocols.  We have groups like gro and dnsop that develop such
recommendations.

For other protocols this makes no sense at all.  In the past I've worked
on VPN deployments for clients.  Those clients chose algorithms that
were right for their environments.  IF within that environment they
happened to choose a protocol that was not labeled as MANDATORY by an
IANA registry, that's totally fine.  Neither the IETF nor the IANA has a
good reason to tell people what IPsec algorithms they need to use in
their operational environment, nor even what algorithms must be enabled
in a given configuration.  If we try, we will be ignored.

This draft conflates implementation requirements with operations
requirements.  In many cases we SHOULD NOT specify operations
requirements.  In other cases, there is no reason to be sure that the
implementation and operations requirements will be the same.

Others have pointed out the broken definition of mandatory.  The
definition at the top of 3.1 provides an escape and makes MANDATORY much
like SHOULD.  However the explanation for what it means for
implementations and operations provides no such escape.

There is a lack of alignment between the implementation requirement and
operations requirement for obsolete: if I'm starting to phase something
out, it is too early to say SHOULD NOT implement.

This draft fails to adequately describe its relationship to RFC 2119.
When should I use MUST?  When should I use MANDATORY?  Why do I need
both?  If you're going to introduce new terms, you need to clearly
specify their applicability.