Subject: Re: [Ltru] LAST CALL REQUESTED

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 01 Apr 2009 16:56:07 +0900

On 2009/04/01 13:33, Mark Davis wrote:
> BTW, can someone point me to the tool for viewing the last call status?

https://datatracker.ietf.org/idtracker/draft-ietf-ltru-4646bis/

Alex, can you give us a hint about when to expect the next steps,
or tell us what you need from our side, if anything?

Regards,    Martin.

>
> Mark
>
>
> On Mon, Mar 2, 2009 at 03:19, Martin Duerst<[email-masked]>  wrote:
>
>> Hello Chris,
>>
>> [I'm assuming you are the acting AD currently.
>> I'm cc'ing Alex so he knows what might be comming up for him.]
>>
>> I'm glad to finally request IETF LAST CALL for
>> draft-ietf-ltru-4645bis(-10) and draft-ietf-ltru-4646bis(-21),
>> the two current WG documents of the LTRU WG.
>> The intended status of 4645bis is informational,
>> the intended status of 4646bis is BCP (BCP 47 together
>> with RFC 4647, which stays as it is).
>>
>> I'm sending the shepherding documents in separate mails,
>> but I'm using this mail as a trigger; that's what Ted Hardie
>> told me to do when I did this thing last time.
>>
>> If I need to do anything else, please don't hesitate to tell me.
>>
>> Regards,    Martin.
>>
>>
>> #-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
>> #-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]
>>
>>
>

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

---

From: Mark Davis <[email-masked]>
Date: Wed, 1 Apr 2009 07:35:51 -0700

Hmmm. I'd seen that page, but there wasn't any progress since 3/9, so I
thought I was missing something.

Mark

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Apr 2009 17:01:38 -0700

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" <[email-masked]>
> To: "Martin J. Dürst" <[email-masked]>; "Mark Davis" <[email-masked]>; "Chris Newman" <[email-masked]>; "Randy
Presuhn" <[email-masked]>; "Addison Phillips" <[email-masked]>; "Doug Ewell" <[email-masked]>
> Cc: "Lisa Dusseault" <[email-masked]>
> 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

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Apr 2009 17:12:10 -0700

Hi -

> To: "Martin J. Dürst" <[email-masked]>; "Randy Presuhn" <[email-masked]>
> Cc: "Mark Davis" <[email-masked]>; "Chris Newman" <[email-masked]>; "Addison Phillips" <[email-masked]>; "Doug
Ewell" <[email-masked]>; "Lisa Dusseault" <[email-masked]>
> Sent: Wednesday, April 08, 2009 4:28 PM
> Subject: Re: AD review of draft-ietf-ltru-4645bis-10.txt
>
> On a somewhat related note: please excuse my ignorance, but what is the
> relationship between ISO639-3 and the updated IANA registry for language
> tags?

693-3 was one of the sources of codes used to form subtags in the
"bulk update" 4645bis.

> On <http://www.sil.org/iso639-3/changes.asp> I read:
>
>  An updated version of the code set will be released once each year, and
> all changes since the inception of the code will be reported on this page.
>
> Who is going to keep the two registries in sync and is this desirable at
> all?

This happens on [email-masked], as a function of the language
subtag reviewer.  See 4646bis section 3.4 (12) (B) and surrounding material.
BTW, these sections show some of the long-standing tension in the work between
the desire for stability and for maintaining alignment.

Randy

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Apr 2009 17:16:10 -0700

Randy Presuhn wrote:
 [...]

>developers would use the RFC rather than the registry.
Either way is fine with me, as long as this was discussed in the WG.

>   recognition, and MUST be updated during AUTH48.]
Ah, I've missed that. Thanks.

>I'd like to even consider.
>
I understand. No, I am not asking for this.

>I think the scientific term is "a gazillion,"
>detailing the nature of the change),
>
That what I had in mind.

>but only if (1) necessary to clear a
>DISCUSS, and (2) endorsed by the WG.
>
This is fine with me.

>However, my strong preference
Ok.

After your explanation I think the sentence that reads "This memo is a 
new work, not an incremental update of [RFC4645]" should be reworded or 
removed. Otherwise it is just asking for a question: "if this is new 
work, how come it is 4645bis"? At least it is not clear to me what the 
WG is calling "new work".

---

From: John Cowan <[email-masked]>
Date: Wed, 8 Apr 2009 20:18:25 -0400

> WG is calling "new work".

Because it serves the same function as RFC 4645: to initialize the
IANA registry.

-- 
Unless it was by accident that I had            John Cowan
offended someone, I never apologized.           [email-masked]
        --Quentin Crisp                         http://www.ccil.org/~cowan

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Apr 2009 17:23:28 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: "Lisa Dusseault" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Wednesday, April 08, 2009 5:16 PM
...
> WG is calling "new work".

As a technical contributor...

I'd prefer to simply delete the sentence.

Randy

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 09 Apr 2009 16:31:39 +0900

Hello Alex,

> Responding as a co-chair...

Responding as the other co-chair...

>> From: "Alexey Melnikov"<[email-masked]>
>> To: "Martin J. Dürst"<[email-masked]>; "Mark Davis"<[email-masked]>; "Chris Newman"<[email-masked]>; "Randy
> Presuhn"<[email-masked]>; "Addison Phillips"<[email-masked]>; "Doug Ewell"<[email-masked]>
>> Cc: "Lisa Dusseault"<[email-masked]>

Thanks, too!

> shepherd) Martin Duerst's opinion.

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

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

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

> 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:[email-masked]

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 09 Apr 2009 16:47:03 +0900

On 2009/04/09 9:23, Randy Presuhn wrote:
>> To: "Randy Presuhn"<[email-masked]>
>> Cc: "Lisa Dusseault"<[email-masked]>; "LTRU Working Group"<[email-masked]>

Fine with me, too (both technically and as a co-chair).

Regards,   Martin.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 9 Apr 2009 11:58:56 -0700

Hi -

Our AD has made a request:

> To: "Doug Ewell" <[email-masked]>
> Cc: "Martin J. Dürst" <[email-masked]>; "Mark Davis" <[email-masked]>; "Chris Newman" <[email-masked]>; "Randy
Presuhn" <[email-masked]>; "Addison Phillips" <[email-masked]>; "Lisa Dusseault"
<[email-masked]>
> Sent: Thursday, April 09, 2009 11:00 AM
> Doug Ewell wrote:
> > Alexey Melnikov <alexey dot melnikov at isode dot com> wrote:
>
>  [...]
>
> >> 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.
> >>
> > This is a good point.  Technically, I supposed this is not really
> > "4645bis" in the traditional sense.  Rather, it is the accompanying
> > document to 4646bis, in exactly the same way that 4645 was the
> > accompanying document to 4646.
> >
> > The paragraph is correct; 4645bis does not start from zero and apply
> > the 4645 processes, modulo some "bis" changes.  Rather, it starts from
> > the current (post-4645) Registry and applies processes that are
> > similar (but not identical) to those of 4645, against different
> > standards (ISO 639-3 and 639-5).
> >
> > If a change must be made to avoid a DISCUSS, then probably the most
> > sensible change would be to rename the draft.  Listing all the changes
> > from 4645 would be like describing the development of the airplane by
> > starting with a recapitulation of the development of the car.
>
> I would like the WG to reach consensus if the document should be renamed
> or not.
> Personally I would prefer the document to be renamed, as I find the
> whole concept of "this is names as 4645bis, but really isn't" to be
> quite confusing.
> But I can issue IETF LC on the current document, if this is what people
> want.

As co-chair...

The document in question has the file name draft-ietf-ltru-4645bis-10.txt
If we change the name, we'd need to update 464bis accordingly.  I'm not
sure how the I-D tracker tool would handle a name change at this stage
of the process, but I assume the IESG can cope with it.  The question for
this working group is two-fold:
   (1) Do we want to change the name of the file?
   (2) If so, what do we want the new name to be?

We need to hear from the WG quickly so we can put this issue to rest.

Randy

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 9 Apr 2009 12:08:32 -0700

We called it 4645bis mainly because we called 4646bis "4646bis" (that document really is a 'bis' document). And it *is* kind of confusing that the "first" ID by name is the registry and not the "governing document", but that is an artifact of the original RFC number assignment.

Since the ID name doesn't really mean anything and it disappears during the RFC publishing process and since one could make the case that it is the "second" registry mass update, hence 'bis', I think it unnecessary to change the name and would discourage changing it.

If we were to change it, a nice generic name would probably be most appropriate: "draft-ietf-ltru-registry", "draft-ietf-ltru-registry-update" (which is redundant, since 'ltru' stands for Language Tag Registry Update), or even "draft-ietf-ltru-data"??

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Randy Presuhn
> Sent: Thursday, April 09, 2009 11:59 AM
> To: LTRU Working Group
> Cc: Alexey Melnikov; Lisa Dusseault
> Subject: [Ltru] Ltru consensus call: rename 4645bis I-D?
> 
> Hi -
> 
> > Cc: "Martin J. Dürst" <[email-masked]>; "Mark Davis"
> <[email-masked]>; "Chris Newman" <[email-masked]>; "Randy
> Presuhn" <[email-masked]>; "Addison Phillips"
> <[email-masked]>; "Lisa Dusseault"
> > >> If the document is really not a bis draft, then the draft name
> is
> > >> confusing.
> > >
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru

---

From: Mark Davis <[email-masked]>
Date: Thu, 9 Apr 2009 12:10:17 -0700

I agree; it isn't worth futzing with.

Mark

On Thu, Apr 9, 2009 at 12:08, Phillips, Addison <[email-masked]> wrote:

> We called it 4645bis mainly because we called 4646bis "4646bis" (that
> document really is a 'bis' document). And it *is* kind of confusing that the
> "first" ID by name is the registry and not the "governing document", but
> that is an artifact of the original RFC number assignment.
>
> Since the ID name doesn't really mean anything and it disappears during the
> RFC publishing process and since one could make the case that it is the
> "second" registry mass update, hence 'bis', I think it unnecessary to change
> the name and would discourage changing it.
>
> If we were to change it, a nice generic name would probably be most
> appropriate: "draft-ietf-ltru-registry", "draft-ietf-ltru-registry-update"
> (which is redundant, since 'ltru' stands for Language Tag Registry Update),
> or even "draft-ietf-ltru-data"??
>
> Addison
>
> Addison Phillips

---

From: Kent Karlsson <[email-masked]>
Date: Thu, 09 Apr 2009 22:20:01 +0200

> (1) Do we want to change the name of the file?

I think that such a filename change would be quite pointless. That filename
is fine as it is.

    /kent k

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 9 Apr 2009 13:27:02 -0700

Hi -

>    (1) Do we want to change the name of the file?

I think this would be a particularly pointless bit of hoop-jumping.
I would prefer to *not* change the file name unless that's the
only way we can get it through the IESG.

>    (2) If so, what do we want the new name to be?

If we *must* change the name, something like
draft-ietf-ltru-registry-content-reinitialization-data
might make sense, though I don't think it would
really be helpful.

Randy

---

From: Peter Constable <[email-masked]>
Date: Thu, 9 Apr 2009 15:55:57 -0700

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kent Karlsson
Sent: Thursday, April 09, 2009 1:20 PM
To: Randy Presuhn; LTRU Working Group
Cc: Alexey Melnikov; Lisa Dusseault
Subject: Re: [Ltru] Ltru consensus call: rename 4645bis I-D?

    /kent k

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 10 Apr 2009 00:14:09 +0100

Ok, I think I have enough feedback on this. I've requested IETF LC.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 10 Apr 2009 10:04:37 +0900

> Ok, I think I have enough feedback on this. I've requested IETF LC.

To Alex, with co-chair hat on:

Thanks for moving so quickly. However, I strongly suggest to make sure 
LC happens for both 4646bis and 4645bis together.

To the WG, with co-chair hat off:

I agree with everybody that changing the filename at this point is 
pointless.

Regards,   Martin.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 10 Apr 2009 02:09:44 +0100

> LC happens for both 4646bis and 4645bis together.

I am reviewing 4646bis now and this is likely to be the case. In the 
worst case IETF LC for 4646bis might start a couple of days later.