Are we ready to ship this? If we think so, I'll audit the threads once more and update the shepherd report. I can then submit it to the IESG.
-- Jeff > On Dec 3, 2021, at 1:06 PM, Reshad Rahman <reshad=40yahoo....@dmarc.ietf.org> > wrote: > > Fixed in 09: > https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-unsolicited-09 > <https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-unsolicited-09> > > On Sunday, November 28, 2021, 06:32:58 PM EST, Reshad Rahman > <reshad=40yahoo....@dmarc.ietf.org> wrote: > > > Thank you Tom. I did modify the YANG tree by hand because something was wrong > in my environment. Tracking this with > https://github.com/bfd-wg/bfd-unsolicited/issues/2 > <https://github.com/bfd-wg/bfd-unsolicited/issues/2> > > Regards, > Reshad. > > > On Saturday, November 27, 2021, 07:33:55 AM EST, t petch > <ie...@btconnect.com> wrote: > > > On 26/11/2021 17:23, Reshad Rahman wrote: > > I just posted 08, it passed id-nits :-) Seriously, regarding the old > > reference to bfd-yang it could be because 07 was posted before RFC9127? > > Tom, this should address most (hopefully all) of the outstanding comments > > you've provided from Aug 2020, Oct 2021 and Nov 2021. The Aug 2020 ones > > went through the cracks, but I did make sure to add it in github when we > > were reminded. > > Reshad, > > Yes, this addresses my comments. > > I note the use of 'we' in a couple of places and there is currently an > AD who often comments on such. > > I note that under the first augment in the tree diagram there is > +--rw enabled? boolean > while under the second there is > +--rw enabled boolean > The '?' means optional and I do not understand why one is and the other > is not. I did wonder if the Tree diagram reflects an earlier version of > the YANG module or has been crafted by hand. I note that -07 had > 'enable?' without the 'd' in all places. > > I would be happy to see you pressing ahead with -08. > > Tom Petch > > > > Regards,Reshad. > > On Friday, November 26, 2021, 12:12:01 PM EST, t petch > > <ie...@btconnect.com <mailto:ie...@btconnect.com>> wrote: > > > > On 26/11/2021 14:20, Robert Raszuk wrote: > >> 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. > > > > Robert > > > > I cannot recall commenting on 'explicitely'. > > > > My comments about import needing a reference, about Security > > Considerations being out-of-date and the mismatch of prefix between YANG > > module and IANA Considerations are all based on YANG Guidelines where I > > would expect that BCP to trump the discussions of co-authors, whereas my > > comment on a seeming mismatch of references to authors is, of course, up > > to the authors:-) > > > > I would expect the obsolete reference to bfd-yang to have been picked up > > by IDNits which suggests to me that that had not been run on -07 which I > > always take as a red light! > > > > Tom Petch > > > > > >> Many thx, > >> R. > >> > >> On Fri, Nov 26, 2021 at 1:27 PM t petch <ie...@btconnect.com > >> <mailto: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/ > >>> > >>> <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 > >>>> > >>>> . > >>>> > >>> > >> > > > > >
