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

[Randy Bush <[e-mail]>]

romain:

thanks!

> ** Abstract.  Expand ROV on first use.

ack

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

i am a bit slow, so do not see that as a problem.  but i can hack a
repeat in.

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

   BGP Speakers MUST either keep the full Adj-RIB-In or implement the
   specification in Section 4.

was insuffieicnt?  but ok, that para is now

   BGP Speakers MUST either keep the full Adj-RIB-In or implement the
   specification in Section 4.  Conformance to this behavior is a
   additional, mandatory capability for BGP speakers performing ROV.

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

yup

> ** 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?

hmmmm.  i guess i could s/unnecessary//.

randy