Spencer Dawkins has entered the following ballot position for draft-ietf-spring-resiliency-use-cases-11: 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-spring-resiliency-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Ben's point about RFC 2119/8174 requirements keyword usage. For example, I'm looking at the MUST NOT in A first protection strategy consists in excluding any local repair but instead use end-to-end path protection where each SPRING path is protected by a second disjoint SPRING path. In this case local protection MUST NOT be used. and wondering why that's normative. I would have guessed that the point was, "if you use local protection, you're not carrying out the end-to-end path protection strategy that this section describes", but that isn't an RFC 2119/8174 interoperation keyword thing. What am I missing here? I agree with Adam's confusion about Usually, in a normal routing protocol operations, microloops do not last long enough and in general they are noticed during the time it takes for the network to converge. I assumed that this was supposed to say something like Usually, in a normal routing protocol operations, microloops do not last long enough to be noticed during the time it takes for the network to converge. but the current text isn't clear. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
