I am an assigned INT directorate reviewer for draft-ietf-bier-ping-08.txt. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ <https://datatracker.ietf.org/group/intdir/about/>.

Based on my review, the document IS NOT ready to go to IETF Last Call and therefore CANNOT be forwarded to the IESG

There are a number of issues that I think should be addressed before advancing this document...

1. IANA Considerations - The draft calls out in section 5 the creation of a registry and three sub-registries without giving any guidance on how those registries should be managed, per RFC 8126. It is also unclear is section 5.3 is calling for the creation of an IANA registry or not.

2. Section 3.1

    * It is unclear if the two header formats described here both occur in a transmitted frame or if the second header format is a modified version of the first header. If it is the former, it seems odd to have to duplicate versions, message type, protocol, and reserved fields.

     * Is there a requirement that the timestamp formats be the same in both the Echo Request and the Echo Reply? If not, is there a requirement that BFRs MUST support both formats?

     * The description of the Reserved fields seems incomplete. What should a BFR do if the Reserved field is not set to 0?

     * The Echo Request/Reply frame format includes multiple Timestamp Sent and Timestamp Received fields. How are they initialized? Which fields get set by the BFIR and which ones get set by the BFERs?

     * The BFR acronym is used in this section, but not defined in Section 2.1.

3. Section 3.2 - If a BFR does not recognize a TLV, it can send a response with Return Code 2. Does it also drop that frame? What are the frame handling rules for other error-related Return Codes?

4. Section 3.3 - Some of the defined TLVs/Sub-TLVs indicate that they MAY be included. Are there specific conditions in which they are, or are not, included? 

5. Section 4

     * The whole description of the protocol flows would be much better with illustrative sequence diagrams. 

     * The bulleted lists contain entries with narrative comments delineated by '/*' and '*/'. These were hard to parse given the use of '*' bullets. I would suggest converting these narratives to 'Notes:'.

6. Security Considerations - While I see the relationship to traditional ICMP Ping and LSP Ping, the use of multicast-based ping opens up other types of threats. I believe it would be quite useful to articulate how the threats described in RFC 6450 do, or don't, relate to this functionality.