This is a TSV ART review, but it only brings up one transport issue (interval adaptation). It is an update to my review of draft-16 in the light of changes intended to address my comments (and those of others). The headings of my original review are reused, to identify whether each issue is resolved. One of the 2 security issues highlighted in my original review remains undocumented. 1/ Mandatory return path? [RESOLVED]: The intro to the draft now gives an example of a case where multipoint BFD with no return path would be useful. 2/ Mechanism for verifying connectivity, or not? [UNRESOLVED] Two sentences in the introduction still seems to contradict each other (neither have been changed): " As multipoint transmissions are inherently unidirectional, this mechanism purports only to verify this unidirectional connectivity." " Term "connectivity" in this document is not being used in the context of connectivity verification in transport network but as an alternative to "continuity", i.e. existence of a forwarding path between the sender and the receiver." How can this mechanism verify connectivity, but not be used in the context of connectivity verification in the transport network? The email response from Greg Mirsky (coauthor) was: >>This draft defines the base specification for multipoint BFD. In order for multipoint BFD to support the transport-like connectivity verification we need to do work similar to described in RFC 6428. I think this may miss the point of my comment, which was simply that the introduction contradicts itself on this point. Or am I missing something? 3/ Use case [RESOLVED] see #1/ 4/ Interval adaptation [RESOLVED - non-solution though] My original comment: "Text is needed to describe why it is not an issue for the head to be unaware whether it needs to adapt its transmit interval." This was addressed by adding the following: (paraphrasing) "if a tail can't cope with the head's Tx Interval, it can always leave the session." Specifically, If the value of Desired Min TX Interval in the BFD Control packet received by MultipointTail is too high (that determination may change in time based on the current environment) it must be handled by the implementation and may be controlled by local policy, e.g., close the MultipointTail session. Not communicating solves any problem in communications, but it's never a useful solution. 5/ Inability to authenticate the sender with symmetric keys [RESOLVED, but a nit remains...] The 2 paras about this issue are in a section on their own headed "Assumptions" but they no longer contain any assumptions. They would be better placed within Security Considerations (immediately below their current position). 6/ Source address spoofing [NOT RESOLVED] I think Greg (on behalf of the authors) hasn't grocked my point. In response to my point, Greg repeated the procedure in Section 5.13.2 used to demux a BFD control packet. It uses the source address and other info in the packet. However, it cannot know if the source address is spoofed. So I'll repeat my comment: A 3-way handshake makes a protocol robust against simple source address spoofing. Without a 3WHS, surely the spec. needs to highlight this vulnerability or discuss ways to address it or why it is not an issue. 7/ Scope [ALL RESOLVED] 8/ Incremental deployment [UNRESOLVED] The text remains unchanged. There seems to be a misunderstanding about this comment. Carlos Pignataro has explained on the list, but people seem to keep misunderstanding him too. The text in 5.4.1 simply needs to clarify that implementations that do not support the multipoint-BFD specification are not required to use the PointToPoint value of bfd.SessionType (such non-multipoint implementations are point-to-point but they don't have to say they are). ==New Nits== 1. Intro: s/enables a tail monitor availability/ /enables a tail to monitor availability/