Re: [Last-Call] Genart last call review of draft-ietf-bfd-unsolicited-10

[Reshad Rahman <[e-mail]>]

 Dan, thank you for the review. We'll discuss and get back to you.
Regards,Reshad.
    On Wednesday, November 2, 2022, 10:39:51 AM EDT, Dan Romascanu via Datatracker <[e-mail]> wrote:  
 
 Reviewer: Dan Romascanu
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-bfd-unsolicited-10
Reviewer: Dan Romascanu
Review Date: 2022-11-02
IETF LC End Date: 2022-11-14
IESG Telechat date: Not scheduled for a telechat

Summary:

This is a well-written and clear document that describes procedures for
"unsolicited BFD" that allow a BFD session to be initiated by only one side,
and established without explicit per-session configuration or registration by
the other side (subject to certain per-interface or global policies), with the
goal of achieving operational simplification of "sessionless" applications
using Bidirectional Forwarding Detection (BFD).

The document is Ready from a Gen-ART perspective. A couple of editorial nits
need clarification and possible fixes.

Major issues:

Minor issues:

Nits/editorial comments:

1. Section 1 refers to draft-ietf-idr-rs-bfd which has the status Expired in
the Datatracker. Is the intention to stay with the archived version of this
Expired document?

2. Section 3 defines the new state variable Role as 'The role of the BFD
session as per [RFC5880], section 6.1.'.

However, RFC 5880 talks about role as an attribute of the system in session
initialization rather than an

> A system may take either an Active role or a Passive role in session
  initialization.  A system taking the Active role MUST send BFD
  Control packets for a particular session, regardless of whether it
  has received any BFD packets for that session.  A system taking the
  Passive role MUST NOT begin sending BFD packets for a particular
  session until it has received a BFD packet for that session, and thus
  has learned the remote system's discriminator value.  At least one
  system MUST take the Active role (possibly both).  The role that a
  system takes is specific to the application of BFD, and is outside
  the scope of this specification.

I believe that wording in the two documents needs to be aligned.