Re: Purpose (and Naming) of LCCR

On 11/28/2013 1:03 PM, fantasai wrote:
> On 11/28/2013 07:15 AM, Jeff Jaffe wrote:
>> fantasai wrote:
>>> Based on the new Process proposal, I would expect spec work to follow
>>> the following steps:
>>>
>>>   1. Cycle through WD for a long time as feedback and implementation
>>>      and testing and usability experience is gathered. (Since CR
>>>      doesn't signal anything except "we're going to REC in 4 weeks",
>>>      and carries a lot of extra overhead for making substantive edits
>>>      there is no justification at all to move the spec out of WD.)
>>>
>>>   2. Once you have proof of implementability and all the other
>>>      criteria for REC are satisfied other than the last 4 weeks of
>>>      review, and you publish LCCR to give people that last chance
>>>      to stop the presses.
>>
>> This seems different from what is anticipated in the current proposed 
>> Chapter 7.
>
> It is, however, the most efficient workflow I can come up with
> and seems to match best what is intended *as written in the
> proposal*, without consideration of any statements made by the
> AB outside the text of the proposal.

Well, imho, the fact that 7.4.2 only shows the plan for implementation 
experience; while 7.4.3 shows the achievement of implementation 
experience - and that testing requirements are met in 7.4.3 anchors my 
view "as written in the proposal".  Not to say this is the right 
ultimate process - but it is what is there.

>
> Perhaps your interpretation of the new proposal is clouded by what
> you know of the old Process and the discussions in the AB. There
> is very little in the new Process that leads me to believe that a
> spec should enter LCCR for any reason other than "we're going to
> REC in 4 weeks". And plenty enough statements to imply that if your
> LCCR period isn't approximately 4 weeks and doesn't end in REC,
> you're doing something wrong.

This might work for you and might work for many groups.  But if a group 
does not want to go through implementation experience and 
interoperability testing until the Director has signed off that the spec 
has achieved wide review and met the requirements it might not work.

For a close community (like CSS) the community might feel that they can 
iterate at WD level, and only enter LCCR when they are 4 weeks from 
REC.  For a diverse community (like tracking protection) the community 
might want to reach LCCR before they take the additional steps.

>
>> You don't need to have proof of implementability to enter LCCR.
>
> Sure. But if the goal is that LCCR lasts only 4 weeks and ends in
> REC, I as a responsible editor wanting to follow the Process in
> letter and spirit as efficiently as I can, will not request LCCR
> until I've got all of my REC-entry requirements in order. Because
> proof of implementability takes a *lot* longer than 4 weeks to put
> together. The 4 weeks is just enough for everyone to check that
> everything's in order, not enough to write a test suite or an
> implementation for any non-trivial technology. And if I'm still
> proving implementability, I'm still at significant risk of needing
> to take substantive changes.
>
> The workflow I outline is based on the following conclusions:
>   * By contrast with the old CR, the new LCCR is not intended to
>     signal anything wrt implementation readiness.

I'm not sure where that conclusion comes from.  Certainly some groups 
will decide on implementation readiness prior to LCCR.  But others may not.

> * A spec should only be in LCCR for something like 4 weeks.
>   * LCCR transitioning back into LCCR (and thus any substantive
>     change to an LCCR) is not expected. Only LCCRs transitioning
>     to RECs are expected.
> which are drawn directly from the text, as described in my post.
>
> If you have a dispute with the workflow I outlined either

I don't have a dispute, per se, I'm only reflecting what I think the 
current document suggests.

>
>   A. Dispute the connection between my conclusions and my workflow
>      by showing an alternative workflow that is more consistent with
>      the Process proposal including the conclusions outlined above,
>      and explain how it is more consistent.
>
>   B. Dispute the conclusions I drew from the text by showing how
>      they are wrong, using direct quotes from the Process proposal.

I don't know how you reached your first two conclusions.  I don't see 
where they are supported in the current text.

>
>   C. Dispute that the Process proposal matches your expectations
>      by outlining your desired workflow and informing the AB that
>      the new Process proposal does not encourage it.
>
> C. would be, presumably, hitting this "if" clause:
>> (If, on the other hand, it's not actually what the AB intended,
>> then its new Process draft is all wrong.)

I'm not sure if C hits the "if" clause.   I'm not saying that your 
process workflow is inconsistent with the new proposed process.  It 
could be consistent and correct for some groups.  I'm only saying that 
your process workflow is not the only workflow that is consistent with 
the new proposed process.  The new proposed process is designed to give 
more flexibility for different groups to traverse the path to REC in 
different ways based on their needs.

>
> ~fantasai
>

Received on Friday, 29 November 2013 02:45:35 UTC