--On Friday, 09 September, 2005 08:07 -0700 Doug Ewell
<dewell@xxxxxxxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf