Éric Vyncke has entered the following ballot position for draft-ietf-lsr-l2-bundle-member-remote-id-10: 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-l2-bundle-member-remote-id/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work done in this document. Due to lack of time, I only did a quick review and have identified the following non-blocking issues: ### Section 7 First paragraph: it is unclear whether the 'remote interface identifier' is unique per bundle or per router/node/device or even per network as the 3rd paragraph hints at a central controler? `To verify the correctness of the acquired remote identifiers, implementations SHOULD provide mechanisms` I am afraid that this should not be part of an implementation issue but rather a property if this protocol. I.e., this protocol appears unspecified. Per IESG guidance https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/, explain what are the consequence of bypassing the SHOULD. _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
