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

[[e-mail]]

Hi Jeff, 

Thanks for the follow-up.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Jeffrey Haas <[e-mail]>
> Envoyé : mercredi 5 octobre 2022 22:27
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]
> Objet : Re: Rtgdir early review of draft-ietf-idr-bfd-subcode-03
> 
> 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

[Med] Thanks. I wasn't aware of this repo. Can you please add this link under "Additional resources" in the Datatracker? Thanks.

> 
> 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.
> 

[Med] Thanks.

> 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.

[Med] You are right, however my main comment was about the internal consistency of this document. A reader who is not familiar with the topic will be disturbed by the mix of session vs. connection. Fixing this now will save you a comment during tsv review :-)   

> 
> 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.
> 

[Med] Thanks.

> "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.

[Med] Yes, that's the intent. 

> 
> > ## 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. 

[Med] At least a pointer to rfc5880.html#section-9 should be included here to highlight the issues of BFD on the stability of BGP connections.

 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.

[Med] Not me ;-) I'm for making the IANA operator live easy when dealing with the requested actions. 

> 
> > ## Consider moving at least RFC8538 to be listed as normative.
> 
> That's reasonable.

[Med] Thanks. 

> 
> >
> > # 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.

[Med] This was a minor edit, but we should think about readers who are not familiar with the topic and who should digest this. Fixing this will save you a genart review comment :-)

> 
> 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.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.