Hello Greg, Thank you very much for addressing all my points were applicable. I am changing my ABSTAIN into a NO OBJECTION (even if it does not really matter)
Regards -éric From: iesg <[email protected]> on behalf of Greg Mirsky <[email protected]> Date: Monday, 21 December 2020 at 01:56 To: Eric Vyncke <[email protected]> Cc: Stephane Litkowski <[email protected]>, "[email protected]" <[email protected]>, The IESG <[email protected]>, BESS <[email protected]>, "[email protected]" <[email protected]> Subject: Re: Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT) Hi Eric, apologies for the belated response. Please find my answers below in-lined tagged by GIM>>. Regards, Greg On Wed, Dec 16, 2020 at 2:05 AM Éric Vyncke via Datatracker <[email protected]<mailto:[email protected]>> wrote: Éric Vyncke has entered the following ballot position for draft-ietf-bess-mvpn-fast-failover-13: Abstain 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-bess-mvpn-fast-failover/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. I have balloted ABSTAIN in the sense of "I oppose this document but understand that others differ and am not going to stand in the way of the others." because of the use outside of a node of the IPv4-mapped IPv6 addresses in section 3.1.6.1. A reply on this topic will be welcome. Stéphane in his doc shepherd's write up states that no implementation is known for a document born in 2008... Does the IETF really want to have this on the proposed standards track ? Please find below my ABSTAIN point, some non-blocking COMMENT points (but replies would be appreciated), and one nits. I hope that this helps to improve the document, Regards, -éric == ABSTAIN == -- Section 3.1.6.1 -- I appreciate that the BFD WG relies on "::ffff:127.0.0.0/104<http://127.0.0.0/104>" but those IPv4-mapped IPv6 addresses are assumed to never leave a node and should never be transmitted over the Internet (see https://tools.ietf.org/html/rfc5156#section-2.2). This is the cause of my ABSTAIN. As the inner packet is sent over a tunnel, why not using the a link-local address or the ff02::1 link-local multicast group ? GIM>> This text has been updated. Please let me know if the new text is acceptable: NEW TEXT: o when transmitting BFD Control packets MUST set the IP destination address of the inner IP header to the internal loopback address 127.0.0.1/32<http://127.0.0.1/32> for IPv4 [RFC1122]. For IPv6, it MUST use the loopback address ::1/128 [RFC4291]. == COMMENTS == -- Section 2.3 -- The use of "upstream" and "Upstream" could be confusing... The latter could have been "Upstream PE/ABSR" (often used later in the document) or "ingress node" GIM>> We've tried to clarify the difference in the Terminology section. As I can see from grepping the document, it consistently uses "Upstream PE" (Upstream ASBR is used once). -- Section 3.1.6 -- Could the "BFD Discreminator" attribute be used for other purpose than this document? If so, then why not specifying it in *another* document? Should this document clearly state that it does not define any TLV ? GIM>> Added a note in Section 7.3 BFD Discriminator Optional TLV Type: NEW TEXT: No optional TLV types defined at the creation of the registry. == NITS == As I am probably not the only reader have difficulties to remember RFC contents by their number, may I suggest to prefix the RFC numbers with their titles ? Esp in the introduction ;-) GIM>> I understand the challenge that manner of using references might present. In the Abstract RFC 8562 is referenced by both number and its full title. I'm concerned that doing that in the body of a document might inflate the size. I use HTMLized version that conveniently links the reference and the referenced document.
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
