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.
Regards,Reshad.
On Friday, November 26, 2021, 12:12:01 PM EST, t petch
<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> 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
>>>
>>> .
>>>
>>
>
