# General Area O. Gudmundsson
# Internet-Draft Shinkuro Inc.
# Updates: 5226 (if approved) S. Rose
# Intended status: Standards Track NIST
# Expires: July 31, 2010 January 27, 2010
#
# Definitions for expressing standards requirements in IANA registries.
# draft-ogud-iana-protocol-maintenance-words-03
#
# Abstract
#
# 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.
#
# For example, security functionality in protocols often relies upon
# cryptographic algorithms that are defined in external documents.
# Cryptographic algorithms have a limited life span, and new algorithms
# regularly phased in to replace older algorithms.
#
# This document proposes standard terms to use in protocol registries
# and possibly in standards track and informational documents to
# indicate the life cycle support of protocol features and operations.
As someone familiar with operations of registries I think this document is on
the wrong path. The job of a registry is to maintain the association of
objects with identities. E.g., cars with owners, IP address space with
ISPs, domain names with domain holders, and so on. A uniqueness of the mapping
may be inherent. A registry may offer a history function, that is,
besides reporting the current mapping, a log of past mappings can be found
too. A registry may also store ancillary information to the mapping.
An example of history and ancillary information would be seeing the prices a
house has sold for in the past.
A registry is a reference service. It is best when consulted for information
that can be used to make other judgements. As with just about any other
coordination function, the more (problem) domain intelligence that is built
in, the less flexible the function will be.
As far as IANA's protocol registries, what I want from it is the ability to
look up a value in a parameter registry, get an mnemonic and a reference to
a document. The prime function is from parameter value to meaning (with the
mnemonic being a short hand), the important ancillary information is the
document defining the value.
The document does not have to be an RFC. I would hope that the reference
is not to a person or a mailbox, which is the case in many of the DNS
parameters. (I have spend a lot of time pouring through IANA's DNS parameter
registries over the years.) One other requirement I would suggest is that
the document be one that is "reliable in availability." Stability of the
document is not as important as being able to find the current definition.
My instructions to developers is to begin with the search for "what to
implement" is to start at IANA and then consult all of the references for
the parameters. When answering to an RFP, the RFP will either require
specific RFCs compliance or ask for a list of what the implementation
supports. That is a more authoritative source for "MUST COMPLY" with than
whatever would be in a registry.
The problem with adding compliance requirements to the IANA registries is
that this assumes all implementations are general purpose applications. In
as much as there is no "protocol police" there is no necessity to have
every process listening on port 53 (DNS) to implement the full spectrum
of the protocol's features.
# 1. Introduction
#
# 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.
Perhaps a document should have been produced justifying the obsolescence
of HMAC-MD5, which itself then referenced the original definition, and
have IANA refer people to the document for the discussion.
As a point of text clarity, "the document" refers to what document?
# 1.1. Implementation vs. Operations requirements
#
# It is common that before a new technology is considered "useful" it
# has to gain widespread deployment. Thus it makes sense to have
# different levels of RFC 2119 words requirement on implementations
# than on operations.
I would disagree with that, "popular" would fit better than useful. And
popularity and usefulness are not directly related.
# 3.1. MANDATORY
#
# Implementations: To be considered compliant, all implementations
Compliant with "what" and according to "whom"?
# 4. Protocol Registry Maintenance
#
# Value X in registry Y is "ENCOURAGED". On June 1st 2020 this
# value is to become "MANDATORY".
It is bad form to store future plans in a registry. The future is
not predictable enough (for example see the RIR policies regarding
4-byte AS number registrations - not a registry issue but a comment
on predications) that what is in the registry is meaningful. If this
is done, the risk is that the registry will become to be
untrustworthy if projections are not updated.
Put the temporal information in the referenced documents, not the mapping.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf