Re: [auth48] AUTH48: RFC-to-be 9324 <draft-ietf-sidrops-rov-no-rr-08> for your review

[Randy Bush <[e-mail]>]

my apologies for delay

> 1) <!-- [rfced] Please note that the title of the document has been updated as
> follows: abbreviations have been expanded per Section 3.6 of RFC 7322
> ("RFC Style Guide") and words have been rearranged to avoid awkward
> hyphenation with the expansion. Please review.
> 
> Original:
>   RPKI-Based Policy Without Route Refresh
> 
> Current: 
>   Policy Based on the Resource Public Key Infrastructure (RPKI) without
>   Route Refresh
> -->

sure

> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
> title) for use on https://www.rfc-editor.org/search. 
> -->

bgp

> 3) <!-- [rfced] We have two questions about this sentence:
> 
> Original:
>    When doing RPKI-based Route Origin Validation (ROV) ([RFC6811] and [RFC8481]),
>    and similar RPKI-based policy, if such a BGP speaker receives new
>    RPKI data, it might not have kept paths previously marked as Invalid
>    etc.
> 
> a) We do not see "RPKI-based Route Origin Validation (ROV)" in RFCs 6811 and
> 8481. Are any updates needed here? Note that in RFC 9319, the following
> sentence was included:
> 
>    Please note that the term "RPKI-based Route Origin Validation" and the
>    corresponding acronym "RPKI-ROV" that are used in this document mean the same
>    as the term "Prefix Origin Validation" used in [RFC6811].

good point.  stealing the hack from 9319 seems fine, as does changing
Route Origin to Prefix; though i might prefer the former becuase the
word "origin" is important.

> b) Is "etc." needed at the end of this sentence?
> -->

imiho, yes.  obscure policy might have dropped prefixes marked as other
than invalid.

> 4) <!-- [rfced] Please confirm that "it" is correct here. It seems that "it"
> refers to "BGP Route Refresh". Should "they" be used instead to refer to
> "implementations"? Please review and let us know if any updates are
> needed.
> 
> Original:
>    As Route Origin Validation dropping Invalids has deployed, some BGP
>    speaker implementations have been found which, when receiving new
>    RPKI data (VRPs, see [I-D.ietf-sidrops-8210bis]) issue a BGP Route
>    Refresh [RFC7313] to all sending BGP peers so that it can reevaluate
>    the received paths against the new data.
> -->

yup.  s/it/they/

> 5) <!-- [rfced] Will it be clear to readers what "it" refers to in this sentence?
> 
> Original:
>    If new RPKI data arrive which cause operator policy to invalidate the
>    best route, and the BGP speaker did not keep the dropped routes, then
>    it would issue a route refresh, which this feature aims to prevent.
> -->

so change s/it/the BGP speaker/ if you think it needs disambiguation.

> 6) <!-- [rfced] Please review "global operation, CLI, YANG, etc." here. Also, may
> we update "storing" to "and store"?
> 
> Original:
>    As storing these routes could cause problems in resource constrained
>    devices, there MUST be a global operation, CLI, YANG, etc. allowing
>    the operator to enable this feature, storing the dropped routes.
>    
> Perhaps:
>    As storing these routes could cause problems in resource constrained
>    devices, there MUST be a global operation, CLI, YANG, or other mechanism that allows
>    the operator to enable this feature and store the dropped routes.
> -->

i am fine with the change

> 7) <!-- [rfced] Should "which" here read "that"? (For the difference between
> "which" and "that", please see the FAQ at https://www.rfc-editor.org/faq/#whichthat.)
> 
> Original:
>    Internet Exchange Points (IXPs) which provide [RFC7947] Route Servers
>    should be aware that some members could be causing an undue Route
>    Refresh load on the Route Servers and take appropriate administrative
>    and/or technical measures. 
> -->

do i need to picket your desk again in yokohama?  :)

i went to university of chicago and still do not like the style

> 8) <!-- [rfced] Terminology
> 
> a) We note inconsistencies in the terms listed below. We chose the form on the
> right. Please let us know any objections.
> 
> Route Server vs. route server
>   Note: The lowercase form is used in RFC 7947 and is more common in the RFC Series.
> 
> BGP Speaker vs. BGP speaker
> 
> 
> b) We see instances of both "Route Refresh" (capitalized) and "route
> refresh" (lowercase) in the document. Should the capitalization be
> consistent? Please review and let us know if any updates are needed.
> -->

all fine

> 9) <!-- [rfced] Please review the "Inclusive Language" portion of the online 
> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> and let us know if any changes are needed. Note that our script did not flag
> any words in particular, but this should still be reviewed as a best practice.
> -->

i have tried to be careful of such issues for decades

thanks

randy