Update of the Pseudowire Control-Word Negotiation Mechanism
draft-ietf-pwe3-cbit-negotiation-05

Thanks for addressing all my Discuss and Comment points

This is non-blocking:

To start, realize that I am NOT well versed in PWE3 technology, and please tell me if what I'm asking about would simply be clearly understood by those who are.

In addition to Adrian's rewrite of Section 3 bullet "i" (which I support), I find some other wording clarifications in Section 3 necessary to the understanding of this document:

   Note: the FEC element in label request message should be the PE's
   local FEC element.  Only if FEC element in label request message
   could bind together with peer PE's local FEC element, the peer PE
   sends label mapping with its bound local FEC element and label as a
   response.

I do not understand these two sentences.  What is "should be" in the first sentence?  Is it, or is it not?  I'm not necessarily suggesting changing this to 2119 language, but that you make it clear what you're saying.  The second sentence is just unparseable, and I'm not at all sure that I understand what it's trying to say.

   When Local PE changes the use of control word from PREFERRED to NOT
   PREFERRED, Local PE would be able to re-negotiate the Control Word to
   be not used following the procedures defined in [RFC4447], and no
   label request message to peer PE will be needed.  In that case, Local
   PE will always send new label mapping with C-bit reflecting the
   locally configured preference for use of Control Word.

I'm having a hard time with this paragraph, and don't think I understand it.  I think "to be not used" may be throwing me... apart from its not parsing, I *think* it says that you won't use the Control Word (please use consistent capitalization -- you have it capitalized and not capitalized in the same sentence here) in this case.  Is that right?  Does that make sense?  Then the next sentence talk about using the Control Word.  Please rephrase this paragraph, or assure me that anyone who understands PWE3 will get this, and that's just not me.

I *very* much appreciate and applaud the work done by our non-native-speaking colleagues.  With that in mind, I strongly suggest an editing pass by a native speaker who is familiar with the technology, to correct articles, number, tenses, and punctuation.  The RFC Editor will do this, of course, but they are not technology experts, and may make errors that will be hard to detect during AUTH48.

I support Adrian's DISCUSS position on the process used to advance this document.

General: If this draft is about generic renegotiation it should just say that ;)

This is just word smthing:

(section:change - a=abstract)

- a and s1:

OLD:

The control word negotiation mechanism specified in RFC4447 has a problem when PE changes the preference for the use of control word from PREFERRED to NOT-PREFERRED. This draft updates RFC4447 by introducing a message exchanging mechanism to resolve this control word negotiation issue.

NEW:

The control word negotiation mechanism specified in RFC4447 does not support renegotiation of a Provider Edges (PEs) when its changed from NOT-PREFERRED to PREFERRED.   This draft updates RFC4447 by introducing a renegotiation mechanism.

use [RFC4447] in s1.  if it's generic then you could drop the "when ..." bit.

- I think you cold delete s2 entirely and add the following paragraph to s1:

The negotiation mechanism described in [RFC4447] addresses receipt of Label Mapping before one is sent and if a Label Mapping message has not been received.  It does not support PE's changing their control word setting after the PW has been established from NOT-PREFERRED to PREFERRED.

- s3, 1st para: 

OLD:

In order to resolve above problem, the control word re-negotiation mechanism as described in [RFC4447] section 6 is updated by adding label request message.

NEW:

[RFC4447] section 6.2 is updated to add the control word re-negotiation mechanism described in this section.

- s3.1, bullet i: Couldn't parse it.

- Adrian's process questions in his discuss seem reasonable to me,
as does the question about how this updates 6073.

- PE could usefully be expanded in section 1.

- The abstract talks about the PREFERRED->NOT-PREFERRED transition,
but section 2 talks about the NOT-PREFERRED->PREFERRWED transition
at PE2. That confused me, since the abstract implies only the
PREFERRED->NOT-PREFERRED transition is problematic.

- Is it "NOT PREFERRED" or "NOT-PREFERRED"? Pick one.

- Section 5: I assume the security considerations from 4447 and/or
6073 apply here as well. Worth saying?