Re: [mpls] MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv

["Adrian Farrel" <[e-mail]>]

Hi Greg,

Thanks for the review.

> firstly, I'll address format of MPLS-RT review as set by WG chairs:
> • The document is coherent, clearly useful and technically sound
> • The document is ready to be adopted by MPLS WG

Thanks for that.
 
> Now several comments and possible typo corrections:
> • Perhaps re-word "No Associated Channel Type yet defined
>  uses a TLV" into "So far none of defined Associated Channel 
> Types uses a TLV as specified by RFC 5586". That seems to be
> more accurate as MPLS-TP BFD Proactive CV message format
> uses Source MEP-ID TLV, though not according to RFC 5586, 
> that might be viewed as example of ACH TLV.

Interesting point. Yes, the text should say "ACH TLV" since individual message
definitions are free to use TLVs. This usage finds itself in the main text, so
it is just the Abstract that needs attention.

> • Introduction, first para, first sentense s/is/if/

Yup

> • Introduction, fourth para, in "However, of the 18 ACH Channel Types
> currently defined none allows the use of ACH TLVs [IANA-ACH]" 
> I'd consider s/allows/requires/ to stress that up to now we managed
> to develop protocol suite without use of  a single ACH TLV

I think I disagree. While 'requires' is seemingly stronger, the permissive
nature of 'allows' makes a stronger point here. I.e., not only is the TLV not
required, but it is even not allowed.

> • Introduction, last para "This document determines that ACH TLVs
> are not useful …" might be re-worded to "This document states that
> ACH TLVs, as specified in RFC 5586, are not useful …"

OK.
Makes note to stop using English when writing I-Ds :-)

> • Section 2, note that references to ACH TLVs exist in RFC 5586
> outside of Section 3, e.g. Section 4.2.1.1, p.10, as well as in several
>l figures, e.g. figure 6.

Yeah. Point also made by Lizhong, so I'm updating Section 2 to read...

   Section 3 of RFC 5586 is deleted.

   References to ACH TLVs in Section 4 of RFC 5586 should also be
   disregarded.  Note that the text in Section 4 currently uses phrases
   like "ACH TLV(s), if present" so, with the removal of Section 3 that
   used to define ACH TLVs, they will not be present.

> • Section 3, if motivation of this document is to negate MUST in 
> Section 3 of RFC 5586 that ACH TLV Header preceeds G-ACh message,
> then would following sufficiently express it: "A G-ACh message MAY 
> NOT be preceeded by an ACH TLV Header."

1. "MAY NOT" is the stuff of RFC 6919, not RFC 2119. So you mean "MUST
   NOT".
2. Doesn't deleting the whole section achieve the effect?

I suppose we could add an explicit statement if people feel strongly.

> • Section 6, I think that we might only remove too restrictive
> requirement of RFC 5586 while allowing use of ACH TLV following
> G-ACh message.

I think that once you have started the G-ACh message, you have completely
stopped talking about ACH TLVs. Any TLVs that you encounter will be
message-specific.

There may turn out to be value in the definition of common G-ACh message TLVs,
but that seems to be a decision for the future. What we find (mia culpa) is that
when we specify stuff for which we have no immediate use, we end up wasting our
time.


Now, I have a -02 ready to post, but the chairs slapped my wrist when I posted
-01 during the MPLS-RT review period, so i am left puzzled as to whether I am
allowed to post a new revision of an individual I-D. (Actually, I am not puzzled
at all, since I know how the IETF works. I will nevertheless attempt to be
polite and friendly to the chairs - the shock may kill them :-)

Cheers,
Adrian