Updates to MPLS Transport Profile Linear Protection
draft-ietf-mpls-psc-updates-06

I have no objection, and I think we should do more clarification documents when we find situations such as this.  I do think this could clarify a bit better, so please consider:

Section 2.1 says "network bit order".  Section 2.2 says "network byte order".  Are they meant to be different things?  If not, pick a consistent term.  In either case, a reference defining the term would be useful, just to be sure -- you're clarifying, so it's better clarify as clearly as possible.

I actually still find Section 2.2 somewhat convoluted, as the mention of "The TLV Length" is unclear -- it seems out of place, there in the middle of the detail about individual TLVs.  May I recommend a bit of reorganization here?:

OLD
   [RFC6378] provides the capability to carry TLVs in the PSC messages.
   This section defines the format to be used by all such TLVs.  All
   fields are encoded in network byte order.

   Type field (T):

   A two octet field that encodes a type value.  The type values are
   recorded in the IANA registry "MPLS PSC TLV Registry".

   Length field (L) :

   A two octet field that encodes the length in octets of the Value
   field.

   The TLV Length is the sum of the lengths of all TLVs in the message.
   The length of a TLV is the sum of the lengths of the three TLV
   fields, i.e., the the length of the value field + 4.

   The value of this field MUST be a multiple of 4.

   Value field (V) :

   The contents of the TLV.  This field MUST be a multiple of 4 octets
   and so may contain explicit padding.
NEW
   [RFC6378] provides the capability to carry TLVs in the PSC messages.
   All fields are encoded in network byte order. Each TLV contains
   three fields, as follows:

   Type field (T):
   A two-octet field that encodes a type value.  The type values
   are recorded in the IANA registry "MPLS PSC TLV Registry".

   Length field (L):
   A two-octet field that encodes the length in octets of the Value
   field.  The value of this field MUST be a multiple of 4.

   Value field (V):
   The payload of the TLV.  The length of this field (which is the
   value of the Length field) MUST be a multiple of 4 octets, and so
   this field may contain explicit padding.

   The length of each single TLV is the sum of the lengths of its
   three fields: the length of the value field + 4.  The overall TLV
   Length field in the PSC message contains the total length of all
   TLVs in octets.
END

From the title, abstract, introduction, I see words such as updates, rules, recommendations, corrections, clarifications.

I'm unable to tell if there will be backward compatibly issues between this future RFC and RFC6378
And sorry, I haven't reviewed all the technical details of the update, to make up my mind.
Is this document just text clarifications, or should http://tools.ietf.org/html/rfc5706#section-2.3 be considered?
If the former, clarify this early in the document.
Otherwise, discuss the migration path.

I was about to file a DISCUSS on this, but a quick discussion was beneficial.
He wrote:

    2.1 Just a statement for clarity
    2.2 Just a statement for clarity
    2.3 Clarifies error handling. Might change behavior s.t. a broken message previously accepted is now rejected. This is not a b/w compatibility issue
    3. This could change implementation behavior (if the previous implementer was a literalist fool), but the impact is to make a broken implementation work, so that is not a b/w compatibility issue
    4. Describes how to behave to achieve interop or report inability to interop. Old implementations may have winged it, but probably never had the issue because mismatches would not actually have happened. No b/w compatiblity issues.
    5. This fixes a bug in an obscure double race condition. In the event that a pair of old implementations hit this case they would have frozen, so fixing it is not a b/w compatiblity issue.
    6. Is effectively a statement for clarity. Working implementation I know f already do this. I do know a broken implementation that doesn't do this, with the result that it simply doesn't work. So b/w compatibility is not an issue.

I now understand that there are no "backward compatibility issues".
Simply add: "This document does not introduce backward compatibility issues with implementations of RFC 6378"

Thanks for addressing the security considerations.  I'll look for the updated text in the draft from that review.

I'm clearing my Discuss assuming something like Adrian's proposed text makes it into the doc. 

Adrian's proposed text is :

OLD
2.3.2.  Well-formed but unexpected TLV

   If a message is deemed to be properly formed, an implementation
   SHOULD check all TLVs to ensure that it knows what to do with them.
   A well-formed but unknown TLV value MUST be ignored, and the rest of
   the message processesed as if the ignored TLV did not exist.  An
   implementation detecting a malformed TLV SHOULD alert the operator as
   described in Section 2.3.1.
NEW
2.3.2.  Well-formed but unknown or unexpected TLV

   If a message is deemed to be properly formed, an implementation
   SHOULD check all TLVs to ensure that it knows what to do with them.
   A well-formed but unknown or unexpected TLV value MUST be 
   ignored, and the rest of the message processed as if the ignored TLV
   did not exist.  An implementation detecting a malformed TLV SHOULD
   alert the operator as  described in Section 2.3.1.
END

My Discuss was:

---

This should be a easy Discuss to clear, especially if I don't understand what's going on ...

2.3.2.  Well-formed but unexpected TLV

   If a message is deemed to be properly formed, an implementation
   SHOULD check all TLVs to ensure that it knows what to do with them.
   A well-formed but unknown TLV value MUST be ignored, and the rest of
   the message processesed as if the ignored TLV did not exist.  An
   implementation detecting a malformed TLV SHOULD alert the operator as
   described in Section 2.3.1.

"unexpected" and "unknown" don't mean quite the same thing to me (I think from the paragraph you mean "unknown"), but the Discuss is that the last sentence is saying what should happen if the TLV is malformed, which was 2.3.1, and the section doesn't say what to do if the TLV is unexpected, or unknown or whatever this section turns out to be about. Cut and paste error from someplace?

Could you take a look at this more closely?