[Sidrops] Roman Danyliw's No Objection on draft-ietf-sidrops-rov-no-rr-05: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-sidrops-rov-no-rr-05: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rov-no-rr/



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

Thank you to Mališa Vučinić for the SECDIR review.

** Abstract.  Expand ROV on first use.

** Abstract.  The text already describes the updates to RFC8481:
   This
   document updates RFC8481 by describing how to avoid doing so by
   either keeping a full Adj-RIB-In or saving paths dropped due to ROV
   so they may be reevaluated with respect to new RPKI data.

-- This text in the abstract isn’t repeated anywhere else in the body of the
text.

-- Per the text in Section 5, it also appears that RFC8481 is also updated in
the following way: “Conformance to this behavior is a additional, mandatory
capability for BGP speakers performing ROV” (or something to that effect).

** Section 3.  Typo. s/aginst/against/

** Section 5.
   Operators deploying ROV and/or other RPKI based policies SHOULD
   ensure that the BGP speaker implementation is not causing unnecessary
   Route Refresh requests to neighbors.

Is there any qualification on what constitutes “unnecessary Route Refresh
requests”?  Is it any behavior that does not conform to this document?