Re: [RTG-DIR] Rtgdir early review of draft-ietf-idr-bfd-subcode-03

[Jeffrey Haas <[e-mail]>]

Mohamed,

Thank you for your detailed review.  

While your detailed review in the marked up word document linked in your
original mail is helpful for clarity, it unfortunately is a bit of an
obstacle for the working group to follow the audit trail of our discussion.
I'll be selectively responding to some of your edits in this reply.

I'll also be collecting the edits vs. the github where the draft is
maintained. This is so the end product of reviews can be visible and
iterated over prior to publication of -04.  The location of the repository
is here:

https://github.com/jhaas-pfrc/draft-ietf-idr-bfd-subcode

Work targeting publication will be tracked in branch draft-04.  The branch
contains the current candidate -04 along with the rfcdiff between the
published -03 and the candidate -04.

I'll begin by responding to the substantive comments below, then proceed to
the editorial comments in the referenced .doc.

On Wed, Oct 05, 2022 at 12:24:31AM -0700, Mohamed Boucadair via Datatracker wrote:
> Reviewer: Mohamed Boucadair
> Review result: Has Issues
> 
> Document: draft-ietf-idr-bfd-subcode-03
> Reviewer: Mohamed Boucadair
> Review Date: 05/10/2022
> IETF LC End Date: N/A
> Intended Status: Standards Track
> 
> I have been selected to do a routing directorate “early” review of this draft.
> 
> # General
> 
> The specification is on good track and its core contribution is ready. However,
> there are some very few points that I suggest to fix:
> 
> ## Use consistent terminology (see more in the detailed review provided below)

A challenge the BGP specifications have had over the years is the Working
Group hasn't sufficiently normalized some of the terminology, even within
the base RFC 4271.

One item called out in your text is connection vs. session.  The bulk of
4271 uses the word "connection", although the FSM text heavily uses session.
While I believe session is more correct in this instance, I'll accept your
normalizations toward connection.  We can fight over the semantics if we
ever do RFC 4271-bis.

A further point of contention is consistent capitalization of various
BGP-specific keywords.  RFC 4271 isn't consistent, and this point is
regularly raised while working through the RFC Editor process.[1]
The two items in particular that are flagged:

"BGP Speaker" vs. "BGP speaker": As much as I prefer the former, the latter
has better support in the BGP document series.  I'll make those updates.

"subcode" vs. "Subcode".  The latter is used often in documents, but also
inconsistently.  See RFC 4486 as an example.  I'll be preferring the latter
version and will let this be resolved at the RFC Editor level.

> ## Consider adding a pointer to the BGP YANG module as an example to tweak the
> associated BFD timers. Likewise, consider listing last-error (YANG) data node
> in addition to the MIB mention.

I've added it as an informative reference.  This will prevent the document
from getting stuck at the RFC Editor waiting on normative references.

> ## The Security Considerations Section should ACK at least the dependency on
> the BFD to take actions. Manipulating the BFD session will thus have
> implications on the BGP connection.

I have to fundamentally disagree with this point.  The security implications
of BFD on client protocols is covered in the BFD document security
considerations, particularly in the base RFC 5880.  The only purpose of this
document is to address that when BFD is used to protect BGP sessions that
BGP may wish to report when it is responding to BFD going to the Down state
as its reason for terminating the session.  

> 
> ## IANA Considerations: The assignment is currently temporary (as per
> https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-4).
> IANA should be requested to make that assignment permanent. I would update the
> text accordingly.

Practices for such text when early allocation has been done vary.  I will
leave the existing text, since it's what should occur in the document as
part of publication as an RFC.  I have added a "request to IANA, to be removed
by RFC editor" section to make you happy.

> ## Consider moving at least RFC8538 to be listed as normative.

That's reasonable.

> 
> # Detailed Review:
> 
> FWIW, my detailed review can be found at:
> 
> * pdf:
> https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-idr-bfd-subcode-03-rev%20Med.pdf

Specific commentary:
"BFD is utilized as a service for various network functions (a.k.a., BFD
clients or clients for short), "

RFC 5882 covers various network functions as clients, and is cited in this
section.  I don't think the text on "network functions" adds clarity.

I'll be retaining the deleted "BGP MIB" text prior to the RFC 4273 citation.
Don't make the users have to scroll to the citations to figure out what four
numbers mean. :-)

> * doc:
> https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-idr-bfd-subcode-03-rev%20Med.doc

-- Jeff

[1] The Working Group is in need of a style guide for capitalization of
keywords.  If anyone is wanting to own the editorial pen for such a thing,
please contact the idr-chairs.