Peter, Thanks again, I'll take of those acronyms.
Cheers, Andy On Fri, Oct 16, 2015 at 4:49 PM, Peter Yee <pe...@akayla.com> wrote: > 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:agma...@gmail.com] > *Sent:* Friday, October 16, 2015 1:55 AM > *To:* Peter Yee > *Cc:* draft-ietf-pals-ms-pw-protection....@ietf.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 <pe...@akayla.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 > > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
