Roman Danyliw has entered the following ballot position for draft-ietf-spring-segment-routing-mpls-19: 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-segment-routing-mpls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Section 1. Shouldn’t RFC8402 be “[RFC8402]”? (2) Section 1. First use of the acronym, but above there was no “Segment Routing (SR)”. (3) Section 2.1. Editorial. s/,…,etc/, etc./ (4) Section 2.4. The variable name in the text is “Size” and “size” in the equation. They should be consistent. (5) Section 2.4. Per Step #5 of the collision resolution procedure, could you please clarify what is a “non-zero algorithm”? (6) Section 2.5.1. Could you please clarify what “better administrative distance means”. Per the tie-breaking rules above, I assume you mean it is a lower administrative distance. (7) Section 2.5.1, for the sub-bullets under “The fields of each FEC are encoded as follows”, consider adding periods to the first two bullets: s/significant bits are set to zero/ significant bits are set to zero./ s/the numerical value for IPv6/the numerical value for IPv6./ (8) The Security Considerations references [RFC8402] to lay out the assumed trust model and a few of the possible implications (malicious looping, evasion of access control, hiding of the source of DoS attacks) if this model is violated. I concur on the language in the reference. I believe there are a few more things to explicitly point out: ** Per the implications, routing traffic through an observation point controlled by the attacker is another key privacy and integrity concern. ** Per the already stated implication, “malicious loop” feels too soft as the overall availability of the network can be affected (e.g., loops, slowing traffic down). FWIW, I’m not raising this to a DISCUSS because there is no normative language to address these issues, only additional proposed cautionary language of the threat. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
