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

[Jeffrey Haas <[e-mail]>]

Med,

On Thu, Oct 06, 2022 at 06:34:37AM +0000, [e-mail] wrote:
> > 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.

Done.

> > 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 :-)   

You'll note that this was done in the -04 candidate in the repo.

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

It's still inappropriate.

This document doesn't discuss how to apply BFD to the BGP session - that is
covered by RFC 5882.  Such comments would be appropriate in that space.

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

20 years into IETF and this is the first time I've seen anyone concerned
over this detail.

In any case, the text is there and now becomes more work for the RFC Editor
to remove.

> > 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 repeat the same conversation with the genart reviewer and during IESG
review, if it comes to that.  It doesn't add to the clarity.

At this point, I believe I've addressed the points we can agree on.  When
you can, please update the rtgdir review in the datatracker.  If you still
strongly believe in the two open items above are substantive, flag them and
it'll come up during relevant IESG discussion.

There's an opsdir review still pending, so I'll hold publishing -04 until
after they send in their commentary.

Thanks!


-- Jeff