Border Gateway Protocol 4 (BGP-4) Send Hold Timer
draft-ietf-idr-bgp-sendholdtimer-15

Yes

Gunter Van de Velde
Jim Guichard
John Scudder
Roman Danyliw
Warren Kumari

No Objection

Deb Cooley
Erik Kline
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Zaheduzzaman Sarker
Éric Vyncke

Note: This ballot was opened for revision 14 and is now closed.

Gunter Van de Velde
Yes
Comment (2024-08-01 for -14) Not sent 
Thanks for all the great work by the WG embraced within this document.
I have been following the elaborative discussions on the email lists.
Jim Guichard
Yes
John Scudder
Yes
Comment (2024-07-30 for -14) Sent 
Thanks for all your work on this document. I have one comment, related to the use of the “OLD/NEW” idiom. Since the conceit with this idiom is that we are doing a patch to the underlying document, this particular patch:

```
   NEW

   |  SendHoldTime is an FSM attribute that stores the initial value for
   |  the SendHoldTimer.  If SendHoldTime is non-zero then it MUST be
   |  greater than the value of HoldTime, see Section 5 for suggested
   |  default values.
```

strictly speaking means that the reader should go look in section 5 of RFC 4271 for the suggested default values. Of course, what you really mean is section 5 of the present document. I don’t think this is likely to confuse any reasonable reader. Still, it would be cleaner to move the reference to section 5 outside of the “NEW” block, or otherwise disambiguate.
Roman Danyliw
Yes
Warren Kumari
Yes
Comment (2024-08-07) Sent for earlier 
Thank you for writing this document - this feels like it should not be needed, but now that I understand the failure mode, I realize that I've seen this failure mode myself in production (or at least something that looked identical - debugging this is hard!)

Also much thanks to Victor Kuarsingh for the OpsDir review (https://datatracker.ietf.org/doc/review-ietf-idr-bgp-sendholdtimer-13-opsdir-lc-kuarsingh-2024-07-14/) and to the authors for responding.
Deb Cooley
No Objection
Erik Kline
No Objection
Mahesh Jethanandani
No Objection
Murray Kucherawy
No Objection
Comment (2024-08-07) Sent 
Although the shepherd writeup is really thorough, it didn't really give a complete answer to #11.
Orie Steele
No Objection
Paul Wouters
No Objection
Comment (2024-08-07) Sent 
One small comment:

(optionally) sends a NOTIFICATION message with the BGP Error Code "Send Hold Timer Expired" if the local system can determine that doing so will not delay the following actions in this paragraph,

Wouldn't this be the case by definition?

Perhaps "not unreasonably delay" or "not significantly delay" ?
Zaheduzzaman Sarker
No Objection
Comment (2024-08-08) Sent 
Thanks for working on this specification. Thanks for great Shepherd's write up. This specification looks good to from transport protocol point of views (yeah you drop TCP connections :-)).
Éric Vyncke
No Objection
Comment (2024-07-31 for -14) Sent 
Thanks for the work done in this document. I have only two comments (feel free to ignore).

As RFC 4271 has been updated by several RFCs, I am trusting the authors that this update is compatible with all these update, e.g., in section 3.2 there is an event 29 that should not overwrite an event from the previous update RFCs.

I think that readers would welcome a short description in the introduction on how the mechanism works in addition to the FSM update.