Éric Vyncke has entered the following ballot position for draft-ietf-lsr-flex-algo-24: 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-lsr-flex-algo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-lsr-flex-algo-24 CC @evyncke Thank you for the work put into this document. The underlying concept is brillant and can be useful, but it was hard for me to understand all the details as the document is rather tedious to read (and to author -- so congrats!), I may have misunderstood several points. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Acee Lindem for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. ***But***, I regret the lack of reply to the question about `WG discussion and conclusion regarding the IPR disclosures`. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### Alvaro's DISCUSS Just to write that I find Alvaro's DISCUSS points sensible, but I am sure that the authors will address those points. ### Who allocates the flex algo ID After reading the I-D (and skipping some too deeply technical parts to be honest), I still wonder whether it is the operator who defines locally significant flex algo ID or whether it will be the IETF by standard actions. I was about to raise a DISCUSS on this point. ### Section 1 For the non-expert reader, it would be nice to shortly indicate why this document is about SRv6 locators and not SRv6 SIDs. (no need to explain this to me BTW ;-) ) ### Section 4 In `We want the mapping`, who is the "we" ? Please do not use such ambiguous sentence patterns. In `As long as all routers in the domain`, what is the "domain" ? The OSPF area? the AS? another concept ? In `The following values area allocated from this registry for Flex-Algorithms`, the reader would benefit to already understand which party (operator/IANA/?) will assign specific values in that range. ### Section 5.1 Even if obvious, it will not hurt to have the unit specified in `Length: variable,`. ### Section 5.1 Calc-Type I am probably confused and lost due to my lack of knowledge... But the definition of Calc-Type: 1) specifies that type 0 is SPF, which is useless as the IANA https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types already says so. I.e., why addin useless/redundant information in the normative part (use of MUST) 2) the same IANA registry https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types has a clear indication that value 2-127 are unassigned. I.e., this I-D should not add constraints in this registry. ### Section 5.1 Priority tie What is the expected behavior when there is a priority tie ? Perhaps add a forward reference to section 5.3 ? ### Sections 6.2 and 6.3 Suggest to repeat the TLV format from section 6.1. ### Sections 6.4, 7.4 Sorry, but cannot understand/parse `Bits that are not transmitted MUST be treated as if they are set to 0 on receipt.` Is the meaning "bits defined by further specification but not in the actual transmitted TLV" ? What is the expected behavior when length is 0, i.e., I would assume that SRv6 nodes will either do not send this TLV or send it with length=0. ### Section 11 Again a "we" in `we say it`, please rephrase without using ambiguous "we". ### Section 20.1 Is RFC 8986 really normative? I would have assumed it is informative. ## 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. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments ************* As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion; I really think that the document would be improved with a change here, but can be convinced otherwise. Check for IPv4, IPv6, address, NAT, ICMP, MTU As usual, as the responsible AD for the ADD WG, I have done an AD review before the IETF Last Call. Please find a MD-formatted review below. Before going further, I am requesting the authors to act/reply/comment on all the points below. The end goal is to ease the rest of the publication process. Please note that Tim Winters is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well when Tim will complete the review (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-ippm-rfc8321bis/reviewrequest/16061/ _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
