Dan, thank you for your review. I have entered a Discuss ballot for this document based on my own review. Lars > On Nov 2, 2022, at 16:39, Dan Romascanu via Datatracker <noreply@xxxxxxxx> 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. > > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
