[Sidrops] Robert Wilton's No Objection on draft-ietf-sidrops-rov-no-rr-06: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-sidrops-rov-no-rr-06: 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:
----------------------------------------------------------------------

Hi,

I found this document pretty easy to read, so thank you for that.  Here are
some comments that might improve the document, that perhaps you may have
already addressed:

1.
   but on the order of
   the in-degree of ROV implementing BGP speakers.

Being ignorant, I didn't know what "in-degree" meant before I looked it up. 
Possibly, clarifying here would be beneficial.

2.
   As storing these paths could cause problems in resource constrained
   devices, there MUST be a knob allowing operator control of this
   feature.  Such a knob MUST NOT be per peer, as this could cause
   inconsistent behavior.

I would suggest that you use text like "config setting" rather than "knob".  I
think that it would be useful to understand whether there is any IETF YANG
configuration module to control this behaviour, either existing, or in the
works.

3.
   Such a knob MUST NOT be per peer, as this could cause
   inconsistent behavior.

Would this necessarily give inconsistent behaviour?  Wouldn't it just mean that
it would always need to resync against some BGP peers, but not others?  It
feels quite prescriptive for an RFC to be banning more granular configuration
options.

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

Given these are "unnecessary Route Refresh", I was wondering why this couldn't
be a MUST rather than a SHOULD.

5.
   If the BGP speaker has insufficient resources to support either of
   the two proposed options,

It was not 100% clear to me what the two proposed options are, I'm presuming
that it is: "BGP Speakers MUST either keep the full Adj-RIB-In or implement the
specification in Section 4.", but perhaps worth considering if this could be
made clearer.

Regards,
Rob