Andrew,
Regarding Appendix A, that may just be my lack of deep
understanding for the MPLS-TP world. If you feel the differentiation is
covered, leave it as is.
Acronyms that might merit expansion include PE (as used in T-PE
and S-PE), PSN (one meaning is well-known, the other not), CE (several possible
expansions for this one), and G-Ach.
Kind regards,
-Peter
From: Andrew G. Malis [mailto:agmalis(_at_)gmail(_dot_)com]
Sent: Friday, October 16, 2015 1:55 AM
To: Peter Yee
Cc: draft-ietf-pals-ms-pw-protection(_dot_)all(_at_)ietf(_dot_)org; General
Area Review Team; IETF Discussion; BRUNGARD, DEBORAH A (ATTLABS)
Subject: Re: Gen-ART LC/Telechat review of draft-ietf-pals-ms-pw-protection-03
Peter,
Many thanks for your review. My response is inline:
On Fri, Oct 16, 2015 at 4:07 AM, Peter Yee <peter(_at_)akayla(_dot_)com> wrote:
I am the assigned Gen-ART reviewer for this draft. The General Area Review
Team (Gen-ART) reviews all IETF documents being processed by the IESG for
the IETF Chair. Please wait for direction from your document shepherd or AD
before posting a new version of the draft.
For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-pals-ms-pw-protection-03
Reviewer: Peter Yee
Review Date: Oct-15-2015
IETF LC End Date: Oct-15-2015
IESG Telechat date: Oct-22-2015
Summary: This draft is basically ready for publication as a Standards Track
RFC, but has nits (and a question) that should be fixed before publication.
[Ready with nits]
The draft provides two mechanisms that can be used to provide protection to
static Multi-Segment Pseudowires against failure of switching Provider Edge
nodes. I'm not familiar enough with the topic to determine if the mechanism
works as easily as described in the draft, but the concept helpfully does
not require invention of new protocols, so a determination of suitability
shouldn't be difficult for MPLS experts to make.
Question: Wouldn't it make sense to provide some explanation in Appendix A
for why it exists and when it should be used? Currently it's just offered
as an alternate approach without real guidance.
Appendix A applies to those MPLS-TP networks that are using the PSC protocol
for linear protection. We though that was pretty clear in the first paragraph
of the appendix. I'll see if we can make that more clear.
Major issues: None
Minor issues: None
Nits:
General:
Expand all acronyms on initial use. Some of them are probably well-known in
the MPLS community, but their expansion wouldn't hurt either.
Could you be more specific? On a quick check, the only acronyms I'm seeing that
aren't expanded are MPLS and MPLS-TP, which are included in the well-known
acronym list at https://www.rfc-editor.org/materials/abbrev.expansion.txt .
Specific:
Page 4, 1st paragraph, 1st sentence: replace "MS PW" with "MS-PW" to match
other usage in the document.
Page 4, 2nd paragraph, 2nd sentence: append commas after "which" and "PWs".
Page 4, 3rd paragraph, 1st sentence: replace the comma with a semicolon.
Page 8, Section A.2, 1st paragraph, 1st sentence: append a comma after
"link".
Page 8, Section A.2, 2nd paragraph, 1st sentence: append "entity" at the end
of the sentence. As it is, the sentence ends ambiguously in an adjective.
Page 8, Section A.2, 3rd paragraph, 1st sentence: change "a SS-PW" to "an
SS-PW".
Thanks for the close read, we'll fix these nits.
Cheers,
Andy