Re: [Ltru] AD review of draft-ietf-ltru-4645bis-10.txt

["Randy Presuhn" <[e-mail]>]

Hi -

(I've added the ltru WG list, and trimmed from the recipient list those people
subscribed to that list.)

Responding as a co-chair...

> From: "Alexey Melnikov" <[e-mail]>
> To: "Martin J. Dürst" <[e-mail]>; "Mark Davis" <[e-mail]>; "Chris Newman" <[e-mail]>; "Randy
Presuhn" <[e-mail]>; "Addison Phillips" <[e-mail]>; "Doug Ewell" <[e-mail]>
> Cc: "Lisa Dusseault" <[e-mail]>
> Sent: Wednesday, April 08, 2009 4:10 PM
> Subject: AD review of draft-ietf-ltru-4645bis-10.txt
...
> Ok, here is my AD review of 4645bis. Please let me know if you
> agree/disagree with various issues I've raised.
> Answers to some of my questions might be obvious after I review 4646bis
> in details (I've only skimmed it so far). But I am sending my comments
> anyway in order to speed up the process.

Thanks!

> So far I don't have any issues with the document that I think need to be
> fixed before IETF LC. However, I would appreciate a reply to my review
> before issuing IETF LC. Also please let me know if you want me to last
> call the document as is, or if you would like to update the document to
> address my comments first.

I'd prefer to last call it as is, but would defer to co-chair (and document
shepherd) Martin Duerst's opinion.

> General: I hope the WG has discussed "let's remove all registrations
> from the document before publication" approach. Personally I would
> rather the document contain IANA registrations upon publication.

Yes, this was discussed at some length back when the WG produced RFC 4645.
There was considerable concern that if the content were left in the
RFC, even with health warnings, the risk would be too great that
developers would use the RFC rather than the registry.

> > 1.  Introduction
>
> [...]
>
> >    In its initial phase as an Internet-Draft, this memo also contained a
> >    complete replacement of the contents of the Language Subtag Registry
> >    to be used by the Internet Assigned Numbers Authority (IANA) in
> >    updating it.  This content was deleted from this memo prior to
> >    publication as an RFC.
>
> Is this paragraph useful? If the content is deleted when the updated
> RFC  is published, this doesn't give a reader any useful information. If
> the content is not deleted when the updated RFC is published, then this
> text would be wrong.

It's there to explain the absence of content in the RFC.  Without it,
the document would be puzzlingly content-free.  We were pretty much
painted into this corner by the rules on references to I-Ds, etc.
Back when we did 4645, we considered many alternatives, and this was
the path that got consensus.  When we started the update, the question
was raised whether we wanted to go this route again, but there was
no groundswell of support for any alternative.

> I think there is at least one more place where there is a similar  issue.

There is strong consensus to delete the content upon publication.
If we had known of a tidier way of delivering the bulk update to IANA,
we'd have used it.

I've just picked a nearly random registration from the document:

> > Type: language
> > Subtag: orv
> > Description: Old Russian
> > Added: 2029-09-09
>
> I am confused here. Why is the "Added" date in the future?

See section 2.1:
   The values of the File-Date field, the Added date for each new subtag
   record, and the Deprecated date for each existing grandfathered or
   redundant tag deprecated by this update were set to a date as near as
   practical to the date of IESG approval of this memo.  [RFC EDITOR
   NOTE: these dates are initially set to 2029-09-09 for easy
   recognition, and MUST be updated during AUTH48.]

> > 6.  Changes
> >
> >    [RFC EDITOR NOTE: this section is provided for the convenience of
> >    reviewers and will be removed from the final document.]
> >
> >    This memo is a new work, not an incremental update of [RFC4645].  The
> >    procedure for populating the original Language Subtag Registry,
> >    specified by the earlier [RFC4646], is included by reference to
> >    [RFC4645].  Therefore, no changes from [RFC4645] are listed in this
> >    section.
>
> I am not sure I understand this comment and I don't think I find it
> convincing. At least one of the acting ADs thinks that any XXXXbis draft
> must contain "Changes since RFC XXXX" section, which tries to summarize
> all major changes. (I.e. the AD would put a DISCUSS on the document
> until this is resolved). Personally I find a section listing all changes
> to be very useful, but I don't consider lack of it as a blocking issue.
>
> If the document is really not a bis draft, then the draft name is confusing.

We did discuss whether an incremental update or bulk-replace update was
easier to cope with, and opted for the bulk-replace approach.  To describe
the detailed differences in the changes section would be counterproductive at best.
If this MUST be done to clear a potential DISCUSS, perhaps a compromise
would be to add a summary of the form "XXX new records added, YYY old
records modified."  Actually listing all the new ones would NOT be something
I'd like to even consider.  I think the scientific term is "a gazillion,"
and would nearly double the length of the document, which might make it a
little unwieldy.  :-)  I *would* consider asking the editor to list the
ones to which changes (other thatn formatting changes) were made (without
detailing the nature of the change), but only if (1) necessary to clear a
DISCUSS, and (2) endorsed by the WG.  However, my strong preference
is to provide no more detail than is absolutely necessary, particularly
since the body is to be gutted as part of the publication process anyway.

Randy