[Sidrops] John Scudder's Discuss on draft-ietf-sidrops-rov-no-rr-05: (with DISCUSS and COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-sidrops-rov-no-rr-05: 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/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/



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

I'm strongly in favor of this work and glad to see it here.  I do
want to DISCUSS Section 4, though.  I apologize for not having
reviewed and commented on this section before now.

My concern can be summed up as, some of the language of Section 4 while
well-intentioned, can mislead the reader into thinking it's fine to
continue sending Route Refreshes after all.  If you could take a swing
at reorganizing it to mitigate that, it would be great. The most notable
example of a place where the reader could be misled is the third
paragraph, which has the clause "... MUST issue a route refresh".  I
think you are probably meaning to say that such a route refresh would be
a natural consequence of not following this spec (and not saving the
ineligible routes) -- but by using the 2119 keyword you create a
different expectation.

Please let me know if you want to talk this through in more detail.


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

1. I think this paragraph in Section 4 strays into dictating
implementation internals, and so is unsuitable for a protocol spec:

   Policy which may drop routes due to RPKI-based checks such as ROV,
   ASPA, BGPsec [RFC8205], etc.  MUST be run, and the dropped routes
   saved per the above paragraph, before non-RPKI policies are run, as
   the latter may change path attributes.

It's probably harmless to an experienced BGP implementor, so I'm not
going to die on this hill.

2. Can someone please update the replaced-by information to get
draft-ymbk-sidrops-rov-no-rr into the document history?  I had
to dig for it.

Nits:

- s/equiptment/equipment/
- s/equipement/equipment/