Re: [Gen-art] Gen-ART LC/Telechat review of draft-ietf-pals-ms-pw-protection-03

"Andrew G. Malis" <agmalis@gmail.com> Fri, 16 October 2015 15:18 UTC

Return-Path: <agmalis@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0A61A7013; Fri, 16 Oct 2015 08:18:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4ACtllw42dU; Fri, 16 Oct 2015 08:18:18 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A361B310E; Fri, 16 Oct 2015 08:18:17 -0700 (PDT)
Received: by wicgb1 with SMTP id gb1so13656122wic.1; Fri, 16 Oct 2015 08:18:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bNJAqLMRX0QnzwaysO/5G3zJV42pDRuvTukwtGqM+18=; b=QClWUHNKrJHKTIt26ON1GCXB6plc07xb1I6tHKcmMqoTNMtLFKIEzOQkE/fqNYWuq0 z63LnYra9akgIuyJiKDON+YY4h5RvwoEbOuZcUE77RNKOboW2RlTIGRIdUxjIDXXE4gC y4zXa4k63/0glQqtSzmcs4GdQaJHKYHkeWUvVaBw5vqqZYZP9nVT5bgAUCrvNSE8q9ds wWK+CAxXD84CIvyUB7dKnApG5cu5zZ9gxuMhb3UNqjRggZ+oRByZhUMqlUodBUvcCdNf jIm1ZeyRiIeEhejy+VByKjbRsaw2PDy0GaynmuMend2QKxCvdq6Cpgv3yIgtmhKUdZ63 w6Ag==
X-Received: by 10.180.87.138 with SMTP id ay10mr5693135wib.12.1445008695687; Fri, 16 Oct 2015 08:18:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.9.212 with HTTP; Fri, 16 Oct 2015 08:17:56 -0700 (PDT)
In-Reply-To: <012701d10821$ead2edd0$c078c970$@akayla.com>
References: <00f301d107b7$6db17110$49145330$@akayla.com> <CAA=duU0m9XgJ6XYPTZ8M6F4mMzRajZ44cUsSC44Fgt4y=AGaTQ@mail.gmail.com> <012701d10821$ead2edd0$c078c970$@akayla.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Fri, 16 Oct 2015 17:17:56 +0200
Message-ID: <CAA=duU0vRCxb=rrANMZ4QjtqdX_qnPoYN81d681FwCHG0kYSmA@mail.gmail.com>
To: Peter Yee <peter@akayla.com>
Content-Type: multipart/alternative; boundary="f46d044480950108b705223a4ea8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/soPhh6HsXNUje94QMo23YVweJWc>
Cc: General Area Review Team <gen-art@ietf.org>, draft-ietf-pals-ms-pw-protection.all@ietf.org, IETF Discussion <ietf@ietf.org>, "BRUNGARD, DEBORAH A (ATTLABS)" <db3546@att.com>
Subject: Re: [Gen-art] Gen-ART LC/Telechat review of draft-ietf-pals-ms-pw-protection-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2015 15:18:20 -0000

Peter,

Thanks again, I'll take of those acronyms.

Cheers,
Andy

On Fri, Oct 16, 2015 at 4:49 PM, Peter Yee <peter@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:agmalis@gmail.com]
> *Sent:* Friday, October 16, 2015 1:55 AM
> *To:* Peter Yee
> *Cc:* draft-ietf-pals-ms-pw-protection.all@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 <peter@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
>
>
>