[mpls] Ben Campbell's No Objection on draft-ietf-mpls-tp-shared-ring-protection-05: (with COMMENT)
Ben Campbell <email@example.com> Tue, 23 May 2017 19:42 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF4412EA52; Tue, 23 May 2017 12:42:03 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Ben Campbell <firstname.lastname@example.org>
To: "The IESG" <email@example.com>
Cc: firstname.lastname@example.org, Eric Gray <Eric.Gray@Ericsson.com>, email@example.com, Eric.Gray@Ericsson.com, firstname.lastname@example.org
Date: Tue, 23 May 2017 12:42:03 -0700
Subject: [mpls] Ben Campbell's No Objection on draft-ietf-mpls-tp-shared-ring-protection-05: (with COMMENT)
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Tue, 23 May 2017 19:42:04 -0000
Ben Campbell has entered the following ballot position for draft-ietf-mpls-tp-shared-ring-protection-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: - The abbreviation "MSRP" is already used by RFC 4975. Please avoid overloading it if at all possible. (And you probably want to collide with "Manufacturer's Suggested Retail Price" even less.) -4.4.2: "When the service LSP passes through the interconnected rings, the direction of the working ring tunnels used on both rings SHOULD be the same. " Would it ever make sense for the directions to be different? (That is, why not MUST?) If so, a few words about that would be helpful. -5.1, 3rd bullet: "Determination of the affected traffic SHOULD be performed by examining the RPS requests (indicating the nodes adjacent to the failure or failures) and the stored ring map (indicating the relative position of the failure and the added traffic destined towards that failure)." Would it ever make sense to violate that SHOULD? (That is, why not MUST?) -6.2: Why "standards action"? That's a high bar. Are there reasons why a lower bar like "specification required" would not be appropriate? For example, are we in danger of running out of code points? Is this registry at unusual risk for poor quality registrations? Editorial: -3: Is this section expected to be useful to implementors? It reads more like evidence to the WG that this meets the requirements. I suspect people won't much care about that once this is published as an RFC. Please consider moving it to an appendix, or even removing it entirely. -4.4.2: "For example, if the service LSP uses the clockwise working ring tunnel on Ring1, when the service LSP leaves Ring1 and enters Ring2, the working ring tunnel used on Ring2 SHOULD also follow the clockwise direction." Please avoid repeating the 2119 "SHOULD" in the example. - 5.1: "The MSRP protection operation MUST be controlled with the help of the Ring Protection Switch protocol (RPS)." That seems like a statement of fact, rather than an implementation requirement. Starting around 5.1, I notice several uses of the word "source" as a verb, where from context it seems like you mean "to send" or "to originate". Is that a term of art? I usually think of "source" as a verb to mind "acquire","find" or "find a source for" -5.3: "... thus RPS SHOULD be capable of identifying and handling the different failures on the ring ..." That seems like a statement of fact.
- [mpls] Ben Campbell's No Objection on draft-iet... Ben Campbell