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

[Rebecca VanRheenen <[e-mail]>]

Hi Randy,

Thank you for your reply! We have updated the document accordingly. We have a couple of followup questions:


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

What do you think about adding the following at the end of Section 2? Or is another location in the document better? (Note that we will ask the AD to approve added text.)
  
   Note that the term "RPKI-based Route Origin Validation" in
   this document means the same as the term "Prefix Origin Validation"
   used in [RFC6811].


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

Are any changes needed for part b of this question? We are not sure if your response applies to both parts of our question or to only part a, so we want to confirm.

——————————

Updated XML file:
   https://www.rfc-editor.org/authors/rfc9324.xml

Updated output files:
   https://www.rfc-editor.org/authors/rfc9324.txt
   https://www.rfc-editor.org/authors/rfc9324.pdf
   https://www.rfc-editor.org/authors/rfc9324.html

Diff file showing changes made during AUTH48:
   https://www.rfc-editor.org/authors/rfc9324-auth48diff.html

Diff files showing all changes:
   https://www.rfc-editor.org/authors/rfc9324-diff.html
   https://www.rfc-editor.org/authors/rfc9324-rfcdiff.html (side-by-side diff)

For the AUTH48 status of this document, please see:
   https://www.rfc-editor.org/auth48/rfc9324

Thank you,

RFC Editor/rv


> On Dec 5, 2022, at 12:30 PM, Randy Bush <[e-mail]> wrote:
> 
> 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
>