RE: Gen-art LC review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11

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

Thanks Robert,

Will be interested to hear author/shepherd responses to this.

Adrian

> -----Original Message-----
> From: L2vpn [mailto:[e-mail]] On Behalf Of Robert Sparks
> Sent: 07 April 2014 20:41
> To: General Area Review Team;
[e-mail];
> [e-mail]
> Subject: Gen-art LC review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11
> 
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-l2vpn-vpls-ldp-mac-opt-11
> Reviewer: Robert Sparks
> Review Date: 7Apr2014
> IETF LC End Date: 8Apr2014
> IESG Telechat date: not yet scheduled
> 
> Summary: This draft is almost ready for publication as a Proposed
> Standard, but has minor issues (primarily editorial) that should be
> addressed.
> 
> I found this document very difficult to read. It asks the reader to hop
> between sections in unusual ways (for instance, it sends the reader to
> the problem statement section for details on normative behavior). I
> strongly encourage an editorial pass focusing on document structure.
> 
> There are many instances of SHOULD in the document where the text should
> just be using prose instead. It's not always clear when an
> implementation would choose to ignore the SHOULD, and what the
> consequences of that choice would be.
> 
> The document is inconsistent about the level of support needed in the
> network before trying to use this extension.
> Section 5.1.2 says the assumption is everything understands it before
> it's turned on. Section 6 points back to figure 2 and says
> to use the extension over the pw where you administratively know the
> peer supports the extension, and fall back to 4762 for
> everything else. Which of those did you intend?
> 
> Specific comments in document order:
> 
> Section 3.2 paragraph 1: This paragraph would benefit from being broken
> into several. It's hard to find its point. The SHOULD in this paragraph
> is probably not a 2119 SHOULD (this section isn't defining the
> protocol). It would be useful in this overview to explicitly say _why_
> "This cannot be achieved with ... 4762]" at this point in the document.
> 
> Section 3.2 paragraph 2: This SHOULD _is_ defining protocol - shouldn't
> it be in section 5?
> 
> Section 4.1.1 paragraph 3: It took me some time to find Z on the figure.
> It might help to introduce it similar to how you introduce X.
> 
> Section 4.1.2: paragraph 1: I think you meant to reference 4.1.1
> 
> Section 5: The first sentence talks about requirements in section 4.
> Section 4 describes a problem using some examples but doesn't explicitly
> call out requirements. Doing so would help the document.
> 
> Last sentence in 5.1.1 (and several other places in the document):
> Please add an article before "MAC Flush message".  (I apologize for such
> a small nit, but each of these instances made making sure I was reading
> what the sentence intended significantly more difficult).
> 
> Section 5.1.2 first paragraph: This section is defining behavior - why
> are you sending the reader back into the problem statement for detail on
> the behavior?
> 
> 5.1.2 paragraph 2: You meant section 6, not 5.
> 
> 5.1.2 paragraph 3: I can't follow this paragraph's structure. I think
> you're trying to say "An MTU-s or PE2-rs SHOULD send MAC withdraw
> messages as defined in [RFC4762] in cases where the network is being
> upgraded and devices are not capable of understanding the optimized MAC
> flush." (But if so, the next sentence is redundant.) Why is this SHOULD?
> 
> 5.1.3 paragraph 1: Why is this a SHOULD and not a MUST? (Similar
> question for the SHOULD in paragraph 2). It's not clear if you're trying
> to avoid "Some things won't implement this spec" or "Don't do this if
> you haven't administratively ensured every element understands this
> extension first" or something else?
> 
> 5.1.3 paragraph 3: You say "unless specified otherwise". Do you ever
> specify otherwise? Why is this disclaimer here?
> 
> 5.1.3 last paragraph: You meant section 6 not 5.
> 
> 
>