Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt

[Thomas Nadeau <[e-mail]>]

	Generic statements like this are not useful at this point in the process; please be specific and what you object to and what changes you propose to correct them. This will allow the WG to discuss any changes on the list if they are major. What we want to avoid is making changes on the same issue multiple times due to multiple conflicting change requests, or attempting to fix generic comments. 

	--Tom

> Do not support as in the current form document goes beyond mere definition of the new Control Channel type for VCCV.
> And concur with concerns expressed by Yaacov and Carlos.
>  
>     Regards,
>         Greg
> 
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Carlos Pignataro
> Sent: Friday, May 25, 2012 7:15 AM
> To: Yaakov Stein; [e-mail]
> Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt
> 
> PWE3ers,
> 
> I too have strong concerns about this document being WGLCed.
> 
> A meta-concern centers around the scope of this document. My understanding (and please correct this with a citation if I am incorrect) is that there was consensus for this document to define a new CC Type 4 using GAL, but there was not consensus to have this document redefine all Control Channels and their requirement levels (i.e., deprecating or creating rules of use). 
> 
> From the minutes at http://tools.ietf.org/wg/pwe3/minutes we can see that:
>           20 min - General discussion on VCCV for GAL
>           There appear to be two separate issues on the table:
>           1. VCCV support for a PW associated channel that uses the GAL as an
>           alert mechanisms (VCCV Type 4). This is really the subject of the draft.
>           2. What to do about legacy modes, particularly router alert and TTL
>           expiry. This is a separate issue regarding the progress of RFC5085
>           (or some future RFC) to Internet Standard status.
> 
> And this I-D should only deal with issue #1 but not #2. This is also clear from the filename "vccv-for-gal", which was changed from the "vccv-2" of the individual submission to make very explicitly clear this scope.
> 
> However, the title of this I-D is still "Unified Control Channel".
> 
> Additionally I would like to highlight in agreement two issues that Yaakov brought up.
> 
> On May 25, 2012, at 8:09 AM, Yaakov Stein wrote:
> 
>> My comments. Most are editorial (some of the document seems to have been written in haste)
> 
> I believe that the number of editorial issues actually amount to technical concerns. For example, the Title, Abstract, and Introduction speak of things in the scope of a 5085bis. Moreover, the Introduction repeats Figures 1 and 2 and the Acronyms even repeats unused ones (L2SS, LCCE are meaningless and unused in this doc).
> 
> From my perspective, the collection of these editorials amount to a blocking comment.
> 
> 
>>  
>>   If the c-bit is set,
>>   indicating the use of the control word, type 1 MUST be advertised
>>   and type 4 MUST NOT be advertised.
>> Although I personally prefer using type 1 if there IS a CW,
>> I do not recall hearing WG consensus on this.
>> This statement goes further than 5085.
>> I would like to see people explicitly express support for this.
>>  
>>   If the c-bit is not set,
>>   indicating that the control word is not in use, type 4 MUST
>>   be advertised, and type 1 MUST NOT be advertised.
>> Sorry, but I strongly disagree here!!!!!!!!!!!
>> By a show of hands at the last meeting people agreed that router alert could be eliminated.
>> However, it was NOT agreed that TTL expiry was to be eliminated – quite the contrary!
>> So, without CW there are 2 options – the presently available and deployed one of using TTL
>> and this new one.
>> The requirement to support this mode ONLY has NOT received consensus from the WG.
>> 
> 
> Similarly, this seems to contradict the actual document scope. We discussed the best approach for "unification" in Paris and subsequently on email, and it is closer to doing a 5085bis than having a document that does not update to redefine. I object to VCCV-for-GAL going beyond VCCV for GAL.
> 
> As it stands, I do not support this document move forward as is.
> 
> Thanks,
> 
> -- Carlos.
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3