BGP Link-State Extensions for Seamless BFD
draft-ietf-idr-bgp-ls-sbfd-extensions-10
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
Alvaro Retana Yes
Andrew Alston No Objection
Thanks to the authors for this specification. I found the document to be clear concise and easy to understand - and had no issues adding this into our own LS implementation based on the document text.
Erik Kline No Objection
Francesca Palombini No Objection
John Scudder No Objection
Like Lars, I also found the author list to be fairly remarkable, almost one author per page. Many hands make light work, they say.
There is one sentence in the Security Considerations section that I think overpromises:
The IGP instances
originating this information are assumed to support any required
security and authentication mechanisms (as described in [RFC7883] and
[RFC7883]) to prevent any security issues when propagating the
information into BGP-LS.
"To prevent *any* security issues" is quite a promise! I'm sure it's not what you mean, I expect you mean something more like "and therefore the security properties of those underlying mechanisms are assumed". Probably if you just dropped everything from there on, so just ended with "[RFC7883])" the text would be complete and accurate.
Lars Eggert No Objection
The document has six authors, which exceeds the recommended author limit. Has the sponsoring AD agreed that this is appropriate? (Especially since this document is very short.) ------------------------------------------------------------------------------- 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. Section 3, paragraph 7 - of 4 octets for each additional discriminator. - ^^ + by 4 octets for each additional discriminator. + ^^ Document still refers to the "Simplified BSD License", which was corrected in the TLP on September 21, 2021. It should instead refer to the "Revised BSD License".
Martin Duke No Objection
Please expand NLRI on first use.
Murray Kucherawy No Objection
I have the same question about the size of the author list as others have raised. A very minor suggestion: The current Section 1.1 really belongs as 2.1, IMHO.
Paul Wouters No Objection
Note that two styles of tables are used in the document. One uses:
+------------+--------------------------+---------------+
The other uses:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The authors should pick whichever one they prefer. If no strong preference, I encourage you to pick the first style :)
Note that the note about early code point should probably be removed.
Robert Wilton No Objection
Hi, My only comment doesn't directly relate to the content in the document, but I would like to check whether any new YANG data nodes are required to configure, enable, or manage this extension and if so that they are being tracked by the WG chairs, or via another document so that they don't get forgotten. And a +1 on 6 authors on a 7 page document seeming excessive. Regards, Rob
Roman Danyliw No Objection
** Section 6. The TLV introduced in this document is used to propagate IGP defined information ([RFC7883] and [RFC7883]). The TLV represents information used to set up S-BFD sessions. The IGP instances originating this information are assumed to support any required security and authentication mechanisms (as described in [RFC7883] and [RFC7883]) to prevent any security issues when propagating the information into BGP-LS. -- I also share John Scudder’s reservation about this text. In addition to his assessment that the second part of the last sentence over-promises, I believe the first part needs refinement as well. I think were primarily talking about RFC5304 and RFC5310 so let’s also be precise about the security properties in question. Perhaps: NEW The IGP instances originating this information are assumed to support the authentication mechanisms described in [RFC7883]. -- Editorial. Why is [RFC7883] cited as “[RFC7883] and [RFC7883]”?
Warren Kumari No Objection
Thank you for this document -- I found it clear and easy to read. Also, much thanks to Dan for the great OpsDir review - https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ls-sbfd-extensions-07-opsdir-lc-romascanu-2022-04-20/
Zaheduzzaman Sarker No Objection
Thanks for working on this specification. I will have to agree with some of the fellow ADs that number of authors is overwhelmingly large for such an small specification which clearly goes beyond the recommendation on the # of authors.
Éric Vyncke No Objection