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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Thursday, March 18, 2010 09:25 -0400 Andrew Sullivan
<ajs@xxxxxxxxxxxx> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]