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
Regards,Reshad.
On Saturday, November 27, 2021, 07:33:55 AM EST, t petch
<[email protected]> 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
><[email protected]> 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 <[email protected]> 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
>>>>
>>>> .
>>>>
>>>
>>
>
>
