Tom, I have personally addressed most if not all of your comments.
Do you see in version -07 used "aligned" or "explicitely" ? If something was not addressed it was based on the discussion with co-authors. Many thx, R. On Fri, Nov 26, 2021 at 1:27 PM t petch <ie...@btconnect.com> wrote: > On 15/10/2021 20:18, Jeffrey Haas wrote: > > Working Group, > > > > Now that the BFD YANG work is getting ready to pop out of the RFC > Editor's > > queue, it's an appropriate time to finish the last minor details for the > > BFD Unsolicited draft. > > > > Previously, the draft had exited Working Group Last Call with minor > things > > to be resolved, and a process question about where this draft should be > with > > regards to the standard process. Our conversation with our Area > Director at > > that time and other associated IESG members suggested that Proposed > Standard > > status was appropriate. > > > > Greg Mirsky had made a number of comments, several which have been at > least > > partially addressed in the current version of the draft. Note that the > top > > of the thread corresponds to the Working Group feedback during WGLC. > > > > > https://mailarchive.ietf.org/arch/msg/rtg-bfd/naYc-qtNmf8ZH2sRF8S76DqzgYc/ > > > > I encourage the Working Group to review the draft and the comments to > date. > > After resolving them, I believe we're ready to have a shepherd writeup > and > > send this to the IESG. > > Jeff > > My comments from 28oct21 and thereabouts, some of which were first made > in August 2020, have not been addressed (or are being ignored:-( > > The IANA Considerations registers a different prefix to that in the YANG > module; this is a showstopper. > > The Security Considerations for YANG modules are out-of-date. See the > pointer in YANG Guidelines, RFC8407. Fixing this will cause updates to > the I-D References. > > The reference to bfd-yang is out of date - it is an RFC now. > > YANG import MUST be Normative Reference (eg RFC8349) > > Tom Petch > > > ----- > > > > Addressing points Greg has raised: > > - "Does this document update RFC 5881?" > > > > In my opinion, we're introducing no procedural changes vs. RFC > 5880/5881. > > The passive mode documented in RFC 5880 is being leveraged. We're > simply > > not explicitly provisioning the session. Others in the WGLC thread > > support not marking this as an update. > > > > - "node-wise configuration" > > > > I believe that has been addressed in the current version of the draft. > > > > - Greg writes: "The fourth paragraph in Section 2 explains the handling > of > > the first BFD control packet with Your Discriminator == 0, i.e., "it > does > > not find an existing session with the same source address". What > happens > > if the matching BFD session has been found?" > > > > This case could use a small amount of normative text. For reference, > here > > is the text from RFC 5880, §6.8.6: > > > > : If the Your Discriminator field is zero, the session MUST be > > : selected based on some combination of other fields, possibly > > : including source addressing information, the My Discriminator > > : field, and the interface over which the packet was received. The > > : exact method of selection is application specific and is thus > > : outside the scope of this specification. If a matching session is > > : not found, a new session MAY be created, or the packet MAY be > > : discarded. This choice is outside the scope of this > > : specification. > > > > One easy possibility is that there is an existing session, or one > that may > > be failing shortly. Discarding the received packets in this > circumstance > > until there is no existing session might be an appropriate response. > > > > - Greg write: "Does that mean that there will be only one session > > with the same source address despite different destination addresses > > listed?" > > > > One point of comparison is that the single-hop BFD YANG module is > indexed > > on interface and destination address and not source address. > > > > - Greg writes: "the local BFD system assigns My Discriminator to the > > session. Though it is standard (RFC 5880) step, it might be useful to > > mention it." > > > > Since I don't think it brings clarity and distracts from "see the base > > RFC", I would suggest not mentioning it. > > > > - Greg asks about what happens to session state for a session that was > > passive and went down. > > > > Much like Greg, I believe this is an implementation detail but it's > one > > that has impact to things like YANG modules. Since single-hop > sessions > > are indexed based on interface and destination address, permitting > them to > > linger for some period of time might be useful with low danger of > being a > > denial of service vs. the operational state. This would permit a YANG > > notification sent for a session that went down to be able to query > > information from the operational state portion of the module. > > > > If the authors agree, it might be worth a sentence or two mentioning > that > > session state may linger for an implementation-defined period of time > for > > management purposes. > > > > - Session changing from passive to active. > > > > This isn't a normative MAY. > > > > - TTL=255 only RECOMMENDED? > > > > RFC 5881 provides for circumstances where the send-side will always > use > > TTL 255 but validation on reception is optional. > > > > I would support Greg's point by suggesting that the text in the > current > > draft simply be updated to say "follow RFC 5881's GTSM procedures". > > > > ----- > > > > Other notes: > > - The BFD YANG module references will be able to be filled out shortly as > > RFC 9127. > > > > - Update dates appropriately throuhgout the YANG module. Copyright, > > revision, etc. > > > > - The YANG module defines a role. I suggest that the draft should > define a > > State Variable covering this. See RFC 5880, §6.8.1. > > > > ----- > > > > Minor comments on the draft from my most current review. (Line numbers > from > > IETF nits tool.) > > > > 140 On the passive side, the "unsolicited BFD" SHOULD be explicitely > > > > s/explicitely/explicitly/ > > > > 391 interfaces the above check should be alinged with routing > protocol > > > > s/alinged/aligned/ > > > > > > -- Jeff > > > > . > > >
