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

["Martin J. Dürst" <[e-mail]>]

Hello Alex,

On 2009/04/09 9:01, Randy Presuhn wrote:
> 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...

Responding as the other 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!

Thanks, too!

>> 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.

I'd also prefer to last call it as is, unless your comments result in 
(relatively) major changes.

>> 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.

Indeed. This is something that I would by now call well established,
at least between the WG, IANA, and the RFC Editor. I guess we could
even recommend it to other WGs, although there are probably not that
many that face similar problems.

>>> 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.

Yes, in particular also because this way of things worked well the
last time, and there was no indication that it wouldn't this time.

>> 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.

I very much agree with Randy here. I think one way of describing the 
differences to RFC 4645 would be to say that they are the the sum of
a) changes to the IANA registry since it was set up with RFC 4645,
    as documented by the registration process (pointer to ietf-languages
    mailing list,...)
b) changes to the IANA registry as documented in the draft itself

It is b) that any actual or potential implementer should care about. 
Anybody interested in the differences between RFC 4646 in draft stage 
and the current draft would do so only for pure curiosity, unrelated to 
implementation/deployment issues.

There is also the question of what exactly "bis" means. The original 
Latin meaning seems to mean just "twice". One use I know of is as an 
additional label when inserting new paragraphs or chapters into a law. 
In that case, e.g. 45 and 45bis are related only by proximity (of 
location and topic, the later being the reason for the former), but 
45bis is explicitly not a revised version of 45, otherwise, 45 would 
have been updated/amended directly, rather than inserting a new 45bis.
In the IETF, 'bis' usually denotes a new version of something existing, 
but I'm not aware of any provisions that require this to be a strict, 
direct update. It was very natural for the WG to call this 4645bis in 
parallel with 4646bis, and because in many ways it actually is a new 
version of 4645, it is 4645 all over, although with a the twist that in 
the meantime, the IANA registry has evolved.

In conclusion, I very much understand said ADs desire to have changes to 
specs clearly documented, and I guess I'd ask for the same if I were in 
his/her position. However, I hope it is clear from all of the above that 
for our specific situation, 4645bis is slightly different in function 
from an average draft-bis, and that documenting the full differences 
between 4645 and 4645bis wouldn't make sense operationally, and that we 
have documented the differences in as far as they are relevant and 
sensible. Personally, I also hope that said AD will be open to the 
argumentation given above, and I promise to make every effort to 
convince him/her, unless you (Alex) think that such convincing efforts 
are a lost cause in the first place.

Regards,    Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[e-mail]