[Idr] Alissa Cooper's Discuss on draft-ietf-idr-rfc8203bis-07: (with DISCUSS and COMMENT)

[Alissa Cooper via Datatracker <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-idr-rfc8203bis-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-rfc8203bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

"If a Shutdown Communication longer than 128 octets is sent to a BGP
   speaker that implements [RFC8203], then that speaker will treat it as
   an error, the consequence of which is a log message.  For this
   reason, operators would be wise to keep shutdown communications to
   less than 128 octets when feasible."

I have a similar question to what Éric asked. Doesn't the above mostly undercut
the value of doing this bis at all? If operators can't expect longer messages
to be understood, will they implement some kind of policy logic or heuristics
to decide when to try to send them and when not? Otherwise, under what
circumstances will they send them?

Was it considered to instead add a new subcode to the BGP Cease NOTIFICATION
subcode registry to capture this case (admin reset or shutdown with long
shutdown message)? That way at least those who want to use it can differentiate
between recipients that don't support RFC 8203, those that do, and those that
support longer communications. I'm not at all steeped in BGP so I'm happy to
drop this if it's unworkable, but I wanted to ask.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

For the IESG: it would be good to discuss a bit if there is some process we can
use to avoid this kind of oversight (that occurred with RFC 8203) in the
future. i18ndir didn't exist when it was published, but even if it had I'm not
sure we would have caught this.