Lars Eggert has entered the following ballot position for draft-ietf-spring-mpls-path-segment-20: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # GEN AD review of draft-ietf-spring-mpls-path-segment-20 CC @larseggert Thanks to Stewart Bryant for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/8Y8zdymWO5b2jAqASpybK3TbVHU). ## Comments ### Section 1, paragraph 3 ``` However, to support various use-cases in SR-MPLS networks, such as Performance MeasurementSection 3.1, bidirectional path Section 3.2, and end-to-end 1+1 path protection (Live-Live case) Section 3.3, the ability to implement path identification on the egress node is a pre- requisite. ``` This paragraph is really incomprehensible. ### Section 2, paragraph 2 ``` A PSID is used to identify a Segment List. However, one PSID can be used to identify multiple Segment Lists in some use cases if needed. For example, one single PSID MAY be used to identify some or all Segment lists in a Candidate path or an SR policy, if an operator would like to aggregate these Segment Lists in operation. ``` This is confusing. Either a PSID (uniquely?) identifies *one* segment list, or it does not. If it can identify multiple (disjoint?) segment lists, the details of how this works need to be described much more clearly. ### Section 3, paragraph 0 ``` 3. Use cases ``` I assume this section is informational? It would be good to say so explicitly. ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### URLs These URLs in the document did not return content: * https://www.fiberhome.com/operator/product/products/294.aspx.htm ### Grammar/style #### Section 3.2, paragraph 3 ``` trusted domain that spans three sub-domains (Access, Aggregation and Core do ^^^^^^^^^^^ ``` This word is normally spelled as one. #### Section 3.2, paragraph 4 ``` of three sub-paths, one in each sub-domain (sub-path (A->B), sub-path (B->C ^^^^^^^^^^ ``` This word is normally spelled as one. #### Section 3.3, paragraph 1 ``` ub-path is associated with a BSID and a s-PSID. The SID list of the end-to-e ^ ``` Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". #### Section 3.4, paragraph 8 ``` PSID from an egress nodes to an ingress nodes is performed within an SR tru ^^^^^^^^^^^^^^^^ ``` The plural noun "nodes" cannot be used with the article "an". #### Section 5.1, paragraph 3 ``` auses have been implemented in above mentioned New H3C Products(running Versi ^^^^^^^^^^^^^^^ ``` The adjective "above-mentioned" is spelled with a hyphen. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
