ietf
[Top] [All Lists]

Re: Last call comments on LTRU registry and initialization documents

2005-09-08 08:56:37


--On Wednesday, 07 September, 2005 01:10 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:

John C Klensin wrote:

(ii) either put the initialization draft on the standards
track with it or publish it as informational and use the
downref procedure,

That's a formal point:  The initial registry is too long to
put it in the IANA considerations of the main document, and
it will be soon obsolete.  Therefore it had to be a separate
document.

Because the WG wanted a proper last call also for this part
it was published as I-D.  Same idea as for e.g. RfC 4021 - a
part of the header field registry defined in RfC 3864.

Apparently RfC 4021 is "standards track", but "informational"
for the initial registry is also possible.  I don't get the
need for "downref" in this case, the reference to the initial
registry in the main document _is_ only informational.

That wasn't clear from the text, but I may not have read closely
enough.    See below.

Do "informational" RfCs created by a WG get a "last call" ?
I'm not sure what the last paragraph in 2026 4.2.3 means.

Independent of what that paragraph means, it is common for
anything that is presented by the WG to IESG for comment to get
a last call within the WG; I can't imagine a WG chair doing
otherwise.  Whether WG informational documents are then Last
Called to the IETF is up to the IESG and relevant ADs.  There is
no requirement that it be done, but it generally is done if the
AD concludes that the document is likely to be either
consequential or controversial.

Something's odd with the procedures here, I'd be surprised
if RfC 4021 would be promoted on stadards track, it's only
a (now already obsolete) snapshot of a part of a registry.

Personal opinion: What should be done in cases like this is to
structure the I-D so that it clearly differentiates between:

        (i) The specification, rationale, and other contextual
        information for the initial registry contents, and 
        
        (ii) The actual listing of the registry initialization

and that the specification provide for some way of
distinguishing between initial registry entries and subsequent
ones by examining the registry (this could be as simple as the
specification of a particular date.

Then an instruction to the RFC Editor could be included in the
I-D asking that they not publish the initialization document
until the entries have been made in the IANA registry and then
that the list of entries be dropped and replaced with a pointer
paragraph and reference.  That would lead to an RFC that was
clearly informational and fairly short, saving everyone
long-term problems.

For draft-ietf-ltru-initial, that would mean retention of
sections 1, 2, and 4-7 into the RFC but the replacement of
section three with, e.g.,

        "3.  The initial contents of the registry as specified
        in this document are those entries in the IANA registry
        [IANA-registry] with a field-name of "Added" and a value
        of "2005-07-10".  Note that [ltru-registry, Section 3.1]
        requires that an "Added" field appear in each
        registration record and that its Section 3.3(1)
        specifies that field must not be changed after
        registration."

Then you are done.  Presto, clearly informational document,
historical information retained in the registry (which is where,
IMO, it belongs), no chance of anyone ignoring the instructions
in the third paragraph of Section 1 that the initialization list
in the RFC is not the registry, and an RFC that runs around ten
pages rather than 118.  

I think that would be a win all around.  But, again, just my
opinion.
        
 
The documents make reference to the "record-jar" format.  I
believe the text in ltru-registry is sufficient to define
the portion of that spec that is relevant

Yes, the defined format is "inspired by" record-jar, it does
not claim to be the real thing.  E.g. it doesn't have arbitrary
comment lines, OTOH it defines a way to encode Unicode by the
known &#x????; sequences for u+????.

a dependency on a moderately expensive book that could go out
of print as part of the definition for an IANA registry

No, it's also only informational for those interested in "the
real thing" instead of what's used for the registry and future
extension registries. 

I would recommend that, as an editorial matter, use of phrases
like "inspired by" or "derived from" would clear up a lot of
confusion before it starts, making it clear that the book is not
needed.  For example, the beginning of the second paragraph of
3.1 might read 

        'The registry will be in a text file format that is
        fully specified below.  This format was inspired by the
        "record-jar" format [record-jar].'

But, again, this is purely an editorial matter as far as I'm
concerned.

 
incidentally, the reference given is incomplete.

Yes, the draft author knows already how to add the proper ISBN
with xml2rfc, "easily fixed" as you said.  Not referencing the
original idea at all would be wrong.  But the reference in the
initial registry draft is in fact unnecessary.  Think of it as
some kind of "informational credits" in the main document.
 
We also considered a pure 2822-like format with CRLF CRLF as a
record separator, but the WG preferred CRLF "%%" CRLF, that's
all - no copyright traps and no necessity to buy the book (e.g.
I don't have it).

Not a decision on which I'd ever be inclined to second-guess a
considered WG decision.

    john


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