Subject: RE: [Ltru] Re: Approval of two ltru documents

From: "Addison Phillips" <[email-masked]>
Date: Tue, 15 Nov 2005 09:13:45 -0800

There is a historical precedent to the contrary: RFC 3066 and RFC 3282.

They both obsolete RFC 1766, the BCP 47 of its time. On different days.

The material obsoleted by draft-matching in RFC 3066 is non-normative, so I don't think it is necessary to link the two together. But I agree that we should just finish the matching work, given that the IESG didn't buy my argument to separate the two, avoid the whole issue and quit griping about it.

More to the point: would draft-matching become a part of the new BCP 47? Or would it get its own BCP number? I'm not so concerned about now, but about a potential 3066ter being held up by an artificial need to revise draft-matching.

Addison

Addison P. Phillips
Globalization Architect, Quest Software

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Scott Hollenbeck
> Sent: 2005年11月15日 8:03
> To: 'Erik van der Poel'
> Cc: [email-masked]
> Subject: RE: [Ltru] Re: Approval of two ltru documents
> 
> > -----Original Message-----
> > From: Erik van der Poel [mailto:[email-masked]]
> > Sent: Tuesday, November 15, 2005 10:54 AM
> > To: Scott Hollenbeck
> > Cc: [email-masked]
> > Subject: Re: [Ltru] Re: Approval of two ltru documents
> >
> > Scott Hollenbeck wrote:
> > > The answer to that question is included in the "Note to the
> > RFC Editor" that
> > > can be found in the I-D tracker entry for registry-14.  The
> > matching draft
> > > doesn't have an identified status because you guys haven't
> > yet formally
> > > asked the IESG to do anything with the document.
> >
> > That note also asks the editor to publish the registry and
> > initial RFCs
> > at the same time as the matching RFC. So now the registry RFC
> > is being
> > held up by the matching RFC.
> 
> You can't have two documents obsolete an older RFC when the two new
> documents get published as RFCs at different times.  It's all or nothing.
> 
> "held up" is relative.  The normal RFC publication process takes several
> months, so there is almost no chance of the matching draft causing a
> problem
> if the group gets it finished soon.  I will ask the RFC Editor to expedite
> processing of the matching draft to avoid delays once the working group is
> through with it.
> 
> -Scott-
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 15 Nov 2005 12:45:48 -0500

> From: Addison Phillips [mailto:[email-masked]] 
> Sent: Tuesday, November 15, 2005 12:14 PM
> To: Scott Hollenbeck; Erik van der Poel
> Cc: [email-masked]

That wouldn't happen today.  Frankly it appears to be an error.  How can
3282 obsolete something that has already been obsoleted by 3066?

> The material obsoleted by draft-matching in RFC 3066 is 
> non-normative, so I don't think it is necessary to link the 
> two together. But I agree that we should just finish the 
> matching work, given that the IESG didn't buy my argument to 
> separate the two, avoid the whole issue and quit griping about it.

The IESG disagreed with your assessment, hence the need to link the two
documents to make progress.  I do agree that we're spending far too much
time on what is largely a publication formality.

> More to the point: would draft-matching become a part of the 
> new BCP 47? Or would it get its own BCP number? I'm not so 
> concerned about now, but about a potential 3066ter being held 
> up by an artificial need to revise draft-matching.

Both will become BCP 47.  I've already confirmed with the RFC Editor that
one or the other can be obsoleted later on independently of the other if
needed.

-Scott-

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 15 Nov 2005 12:43:05 -0800

> 3282 obsolete something that has already been obsoleted by 3066?

It was a long discussion.... 3282 and 3066 together obsoleted everything in 
1766, but none of them obsoleted all of 1766.

The conclusion at the time was that the term "obsoletes" is a much too 
blunt instrument to show the true relationship between documents, and that 
"obsoletes" links from both documents was slightly less false than 
"updates" links from both documents (which was the other alternative 
fielded) - but that there was no marking using only "obsoletes", "obsoleted 
by", "updates" and "updated by" in the RFC Index that was completely "true".

That experience was part of the impetus for the idea of "ISD" (see newtrk).

              Harald

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 16 Nov 2005 07:06:08 +0100

Addison Phillips wrote:

> I agree that we should just finish the matching work, given
> that the IESG didn't buy my argument to separate the two,
> avoid the whole issue and quit griping about it.

Wasn't only you, I also supported to split it.  Apparently
"they" think that Bruce got it right, and our idea was wrong.

Saying so in an RfC editor note is a bit late, because now we
got no review from Bruce - he has the knack to find all bugs.

> new BCP 47?

Scott's answer:  "Both will become BCP 47"

Ugly.  Brian's "discovery" that BCPs could cover more than one
RfC is rather new.  IMNSHO this is no "feature".

> a potential 3066ter being held up by an artificial need to
> revise draft-matching.

You have extlang-ranges, so at least the syntax is clear.  Bye

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Wed, 16 Nov 2005 07:12:19 -0500

> From: Frank Ellermann [mailto:[email-masked]] 
> Sent: Wednesday, November 16, 2005 1:06 AM
> To: [email-masked]
> Subject: [Ltru] Re: Approval of two ltru documents
> 
> Addison Phillips wrote:
> 

Frankly, no, Bruce's comments weren't the influence.  John Klensin's were,
though they essentially suggested the same thing on this particular point.

-Scott-