[mpls] Ben Campbell's No Objection on draft-ietf-mpls-tp-shared-ring-protection-05: (with COMMENT)

[Ben Campbell <[e-mail]>]

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.