ietf
[Top] [All Lists]

Re: Last Call: draft-ogud-iana-protocol-maintenance-words (Definitions for expressing standards requirements in IANA registries.) to BCP

2010-03-18 09:01:48


--On Thursday, March 18, 2010 09:25 -0400 Andrew Sullivan
<ajs(_at_)shinkuro(_dot_)com> wrote:

...
Moreover, it would be awfully nice if we captured somewhere,
"This algorithm is still required, but it's on its way out,"
and, "That algorithm isn't required yet, but real soon now it
will be."  That way, when a developer of code is trying to
decide what to do, there is a useful guide not only of what
the state of affairs is today, but what it likely will be in
six months, one year, &c.  (I'm aware of the amusement likely
to be caused by the idea that DNSEXT could actually plan what
work will really be done in the next 6-12 months.)
...
Does anyone else think that the distinctions we're talking
about are indeed worth indicating somehow in a registry?  If
so, I think the current draft is a good basis for that work,
even if we determine that the current text is not quite what
we want.

Andrew, it would be awfully nice if narrative information about
the status of a wide variety of standards, and possibly even
contemporary conformance information, were captured and readily
available somewhere, along with information about the
relationships among the various documents that made up those
standards.  What is less clear to me is whether overloading that
information onto IANA registries is the right solution.  I have
my doubts for at least two reasons:

        (1) Many protocols don't have associated IANA registries
        for the critical information.  Creating an incentive to
        create registries to provide this type of information is
        probably not a good idea.
        
        (2) Remember that IANA is technically a separate
        organization.  While the relationship is close and
        cooperative and they have generally been very
        responsive, it seems to me that information about the
        relative status and plans for IETF protocols or pieces
        of them ought to be in a place under the direct control
        of the IETF/IESG, not off in an IANA registry somewhere.

Interestingly, a few mechanisms for handling that sort of
narrative and organizing information were extensively discussed
several years ago.  At the time, the IESG effectively decided
that keeping and organizing that information would be more
trouble than it was worth, at least in part because reviewing
those narrative documents for accuracy would add extra work -- a
problem that would not change if one put the information into
IANA registries instead.  In the ensuing years, the IETF has
changed, the IESG has changed, and situations have changed.
Perhaps it is time to ask the question again -- but to ask the
real question about the importance of that information and how
to organize it, not how to slip some arbitrary subset of it into
a few IANA registries.

If your "broad outline" describes the problem you and Olafur are
trying to solve, I suggest that overloading the information into
IANA registries is the wrong solution, independent of whether
the particular choices of words, etc., are correct.

     john

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>