Benjamin Kaduk has entered the following ballot position for draft-ietf-bfd-multipoint-19: 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/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-bfd-multipoint/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss points! The original Comment portion of my ballot is preserved below for posterity. I am told that the normal usage of the bare term "BFD" has the connotation of refering only to usages in an IP/UDP/MPLS encapsulation (exclusing pseudowires and other more "exotic" encapsulations), so I am not including this in my DISCUSS section. However, it seems unusual to limit the scope of a document in some "random" subsection (here, Section 5.8) with no mention in the general Introduction or Abstract. Is there an improvement to make here? Section 4 [...] If no BFD Control packets are received by a tail for a detection time, the tail declares the path to having failed. For some applications this is the only mechanism necessary; the head can remain ignorant of the tails. It sounds like this might be better said as "the head can remain ignorant of the status of connectivity to the tails"? (That is, the head needs to know at least something about the tails in order to send anything to them, so it is not fully ignorant.) The head of a multipoint BFD session may wish to be alerted to the tails' connectivity (or lack thereof). Details of how the head keeps track of tails and how tails alert their connectivity to the head are outside scope of this document and are discussed in [I-D.ietf-bfd-multipoint-active-tail]. nit: "outside the scope" Section 5.7 It's a little unclear to me why tails must demultiplex on the identity of the multipoint path; (that is, why My Discriminator isinsufficient). Presumably this is just a failing on my end, of course. [...] Bootstrapping BFD session to multipoint MPLS LSP in case of penultimate hop popping may use control plane, e.g., as described in [I-D.ietf-bess-mvpn-fast-failover], and is outside the scope of this document. nit: some articles are missing here; maybe "a BFD session", "in the case of", and "the control plane". Section 5.12.2 MultipointTail sessions MAY be destroyed immediately upon leaving Up state, since tail will transmit no packets. Otherwise, MultipointTail sessions SHOULD be maintained as long as BFD Control packets are being received by it (which by definition will indicate that the head is not Up). Would it be more clear to say "indicate that the head is not Up yet" to distinguish from the case in the first paragraph (where a non-Up state *transition* Section 8 It may be appropriate to make stronger statements about the weakness of MD5 than were valid at the time of 5880's publication. (SHA1 is also not doing so great, but I won't block this work on updating the hash function options.) It would be good to either refer to the bit about shared keys in Section 6 or just move it to this section entirely.
