Early Review of draft-ietf-bier-ping-08
review-ietf-bier-ping-08-intdir-early-haberman-2023-04-14-00

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.