ietf
[Top] [All Lists]

Re: Last call comments on LTRU registry and initialization documents

2005-09-09 08:50:06


--On Friday, 09 September, 2005 08:07 -0700 Doug Ewell
<dewell(_at_)adelphia(_dot_)net> wrote:

John C Klensin <john dash ietf at jck dot com> wrote:

The success or failure of the "foo" registry is
not evaluated on how many foos we can put in to it, or its
comprehensiveness relative to some external foo-list, but on
whether it does the job that the foo-protocol (and maybe foo1,
foo2, etc.), requires.  Normally, we don't even write a
"create the baz registry" document.  Instead, we write a "baz
protocol specification" document and include a more or less
long section that instructs IANA to create the registry, what
to put in it, and how.

So, do you propose that we withdraw the specification of the
initial registry contents, all 963 tags and subtags, and
replace it with a set of instructions to IAN on how they can
duplicate our work?  And cross our fingers that they get it
right, or prepare to go through item-languages for any
correctible errors or omissions they may introduce, and live
with the uncorrectable errors?  Just wondering.

No, no.  And I don't understand how you could read that into
anything I wrote.

But let me try to spell that comment out in different language,
just to be sure that we both understand what I was suggesting:

        (i) Internet-Drafts and RFCs are different creatures.
        It is perfectly acceptable, indeed common, to have text
        in I-Ds that no one intends to see in a final RFC.
        
        (ii) The IESG can instruct IANA to form a registry
        and initialize it with any set of instructions that are
        clear enough for IANA to follow accurately.   Those
        instructions can be in an RFC, in an I-D, in a formal
        IESG note to IANA, or, in principle, written on the
        back of an envelope.  It is usually assumed that
        mechanisms that are public and leave tracks are better
        than those that don't, but even that is not a
        requirement.

So, all I was suggesting wrt the text of the "initial" document
is that, when the IESG concluded that it had reached community
consensus, two things should happen:

        (1) The IESG instructs IANA to create the registry,
        populating it with the elements as instructed in the
        Internet-Draft  and using the formats specified there
        and in the "registry" I-D.  
        
        (2) The document is passed to the RFC Editor for
        publication, but with a note indicating that the 100 or
        so pages of subtags should be dropped and replaced by a
        paragraph that explains how the initial subtags, as
        specified by the WG process, can be identified from the
        registry itself.   I _strongly_ prefer that the relevant
        paragraph be constructed and approved by the WG itself,
        rather than being made up by one or more IESG members; I
        assume the IESG would feel the same way.

For whatever it is worth, this gets you a registry created on
the timeframe of a protocol action, not a wait until an RFC is
about to be published (it is not the only way to accomplish
that, of course).  It gets a RFC that is 100 or so pages shorter
and that eliminates any chance of the contents of the RFC being
confused with the contents of the registry itself (something
that the I-D explicitly warns against).  All other things being
equal, a dozen-page RFC is likely to be finished and posted more
quickly than a 117 page one.  Since the usual practices of the
RFC Editor would not permit the publication of one of these
documents before the other (if you don't know/ understand why,
it is worth your asking), what holds up one document, holds up
both and "faster" is clearly in the interest of the WG and the
community.

How you get from there to "withdraw... replace ...instructions
to duplicate work..." is unfathomable to me, but it certainly
was not what I was suggesting.

That suggestion was just about streamlining with a more
efficient and appropriate way to implement what are, as far as I
can tell, _exactly_ the same set of actions.  Unless I've missed
something, it ought to be problematic only if, somehow, the WG
believes that there is "credit" for an RFC in proportion to its
page count.  That belief would be, AFIK, pretty novel around the
IETF.

    john





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

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