Subject: RE: [Ltru] Re: BCP vs. PS

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 23 Feb 2006 08:32:13 -0800

+1

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: Addison Phillips [mailto:[email-masked]]
> Sent: Thursday, February 23, 2006 11:31 AM
> To: 'Frank Ellermann'; [email-masked]
> Subject: RE: [Ltru] Re: BCP vs. PS
> 
> 
> I thought we had consensus in the WG for STD track. This is 
> the first time
> I've seen a claim that we'd actually have to change the 
> charter to do that.
> In the past, Randy and others have said we could make a 
> consensus decision
> to recommend STD and that this should do the trick.
> 
> Some of us argued that the linkage was wrong at 
> draft-registry time. The
> IESG didn't buy my (or other folk's) arguments and we find 
> ourselves in this
> nether world of waiting for draft-matching to be published as 
> an RFC in
> order to get 3066bis published. Which means that delaying 
> draft-matching is
> as good as blocking 3066bis.
> 
> I think the solution is quite simple:
> 
> 1. Let's finish draft-matching. This removes the argument 
> that we haven't
> provided it. If we focus, we could do a last call soon (since 
> the extraneous
> junk is now Gone).
> 2. Let's petition as a WG for the IESG to make the document on the STD
> track. 
> 
> Either way both documents get published. 
> 
> Addison
> 
> Addison Phillips
> Internationalization Architect - Yahoo! Inc.
> 
> Internationalization is an architecture.
> It is not a feature. 
> > -----Original Message-----
> > From: Frank Ellermann [mailto:[email-masked]]
> > Sent: 2006?2?23? 7:32
> > To: [email-masked]
> > Subject: [Ltru] Re: BCP vs. PS
> > 
> > Scott Hollenbeck wrote:
> > 
> > > The IESG evaluation of the registry document, including
> > > evaluation of last call comments received from outside the
> > > LTRU working group, concluded that the words "successor to
> > > RFC 3066" meant "BCP replacement".
> > 
> > Yes, that's clear, and as there was no clear indication which
> > status the WG wants you were forced to pick either BCP or PS,
> > because there's no "dunno" series.  That sticked, and 3066bis,
> > the first document and sucessor to 3066, is or will be BCP 47.
> > 
> > > The matching document got caught up in that because it is
> > > replacing existing text from 3066.
> > 
> > Why should it be caught ?  The BCP vs. PS issue was seriously
> > discussed for the first document, apparently it's possible to
> > update / obsolete a BCP by a PS.
> > 
> > For the first part you decided BCP.  But I don't see why you
> > should be _forced_ to use BCP also for "matching".  Of course
> > the IESG is _free_ to do this, but not forced.  And the WG is
> > _free_ to propose PS without updating the charter.
> > 
> > > it's much harder for the IESG to do something counter to a
> > > charter that the IESG itself approved.
> > 
> > Not my plan to make it harder.  If the IESG insists on a BCP 47
> > with two documents let them.  I just don't like the concept of
> > one BCP with two documents, especially if the second document
> > is much more like normal "standards track" texts.
> > 
> > > I agree that this isn't an optimal situation for getting the
> > > registry document through the RFC Editor's queue.
> > 
> > Yes, that's too late, you said (quasi-) normative, although it
> > will be only informative, so now it blocks 3066bis.  Probably
> > it couldn't have been published faster with all those appeals.
> > 
> > My BCP vs. PS question is unrelated to the blocked 3066bis -
> > the approval was months ago, I missed the (quasi-) "normative"
> > in its text, sh*t happens.  Maybe the authors also missed it -
> > and if not, what could they do ?  Withdraw the approved text
> > under this condition is not very attractive.
> > 
> > > get the matching document finished.  Your charter says that
> > > should have happened 4 months ago.
> > 
> > Not "my" charter, I didn't see it before the WG existed.  I'd
> > pick less aggressive milestones, and I'd avoid dependencies
> > whereever possible - fortunately there's no "normative" USEAGE
> > anywhere in USEFOR - I'll try to get it removed from USEPRO ;-)
> > 
> >                           Bye, Frank
> > 
> > 
> > 
> > _______________________________________________
> > Ltru mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ltru
> 
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru
> 

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru