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

[Rebecca VanRheenen <[e-mail]>]

Authors,

This is a friendly reminder that we await answers to the questions below and your review of the document before continuing with the publication process. 

Thank you,
RFC Editor/rv



> On Oct 27, 2022, at 12:04 PM, [e-mail] wrote:
> 
> Authors,
> 
> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
> 
> 
> 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
> -->
> 
> 
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
> title) for use on https://www.rfc-editor.org/search. 
> -->
> 
> 
> 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].
> 
> b) Is "etc." needed at the end of this sentence?
> -->
> 
> 
> 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.
> -->
> 
> 
> 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.
> -->
> 
> 
> 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.
> -->
> 
> 
> 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. 
> -->
> 
> 
> 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.
> -->
> 
> 
> 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.
> -->
> 
> 
> Thank you.
> 
> RFC Editor/st/rv
> 
> 
> 
> On Oct 27, 2022, at 12:00 PM, [e-mail] wrote:
> 
> *****IMPORTANT*****
> 
> Updated 2022/10/27
> 
> RFC Author(s):
> --------------
> 
> Instructions for Completing AUTH48
> 
> Your document has now entered AUTH48.  Once it has been reviewed and 
> approved by you and all coauthors, it will be published as an RFC.  
> If an author is no longer available, there are several remedies 
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> 
> You and you coauthors are responsible for engaging other parties 
> (e.g., Contributors or Working Group) as necessary before providing 
> your approval.
> 
> Planning your review 
> ---------------------
> 
> Please review the following aspects of your document:
> 
> *  RFC Editor questions
> 
>  Please review and resolve any questions raised by the RFC Editor 
>  that have been included in the XML file as comments marked as 
>  follows:
> 
>  <!-- [rfced] ... -->
> 
>  These questions will also be sent in a subsequent email.
> 
> *  Changes submitted by coauthors 
> 
>  Please ensure that you review any changes submitted by your 
>  coauthors.  We assume that if you do not speak up that you 
>  agree to changes submitted by your coauthors.
> 
> *  Content 
> 
>  Please review the full content of the document, as this cannot 
>  change once the RFC is published.  Please pay particular attention to:
>  - IANA considerations updates (if applicable)
>  - contact information
>  - references
> 
> *  Copyright notices and legends
> 
>  Please review the copyright notice and legends as defined in
>  RFC 5378 and the Trust Legal Provisions 
>  (TLP – https://trustee.ietf.org/license-info/).
> 
> *  Semantic markup
> 
>  Please review the markup in the XML file to ensure that elements of  
>  content are correctly tagged.  For example, ensure that <sourcecode> 
>  and <artwork> are set correctly.  See details at 
>  <https://authors.ietf.org/rfcxml-vocabulary>.
> 
> *  Formatted output
> 
>  Please review the PDF, HTML, and TXT files to ensure that the 
>  formatted output, as generated from the markup in the XML file, is 
>  reasonable.  Please note that the TXT will have formatting 
>  limitations compared to the PDF and HTML.
> 
> 
> Submitting changes
> ------------------
> 
> To submit changes, please reply to this email using ‘REPLY ALL’ as all 
> the parties CCed on this message need to see your changes. The parties 
> include:
> 
>  *  your coauthors
> 
>  *  [e-mail] (the RPC team)
> 
>  *  other document participants, depending on the stream (e.g., 
>     IETF Stream participants are your working group chairs, the 
>     responsible ADs, and the document shepherd).
> 
>  *  [e-mail], which is a new archival mailing list 
>     to preserve AUTH48 conversations; it is not an active discussion 
>     list:
> 
>    *  More info:
>       https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> 
>    *  The archive itself:
>       https://mailarchive.ietf.org/arch/browse/auth48archive/
> 
>    *  Note: If only absolutely necessary, you may temporarily opt out 
>       of the archiving of messages (e.g., to discuss a sensitive matter).
>       If needed, please add a note at the top of the message that you 
>       have dropped the address. When the discussion is concluded, 
>       [e-mail] will be re-added to the CC list and 
>       its addition will be noted at the top of the message. 
> 
> You may submit your changes in one of two ways:
> 
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format
> 
> Section # (or indicate Global)
> 
> OLD:
> old text
> 
> NEW:
> new text
> 
> You do not need to reply with both an updated XML file and an explicit 
> list of changes, as either form is sufficient.
> 
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text, 
> and technical changes.  Information about stream managers can be found in 
> the FAQ.  Editorial changes do not require approval from a stream manager.
> 
> 
> Approving for publication
> --------------------------
> 
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
> 
> 
> Files 
> -----
> 
> The files are available here:
>  https://www.rfc-editor.org/authors/rfc9324.xml
>  https://www.rfc-editor.org/authors/rfc9324.html
>  https://www.rfc-editor.org/authors/rfc9324.pdf
>  https://www.rfc-editor.org/authors/rfc9324.txt
> 
> Diff file of the text:
>  https://www.rfc-editor.org/authors/rfc9324-diff.html
>  https://www.rfc-editor.org/authors/rfc9324-rfcdiff.html (side by side)
> 
> Diff of the XML: 
>  https://www.rfc-editor.org/authors/rfc9324-xmldiff1.html
> 
> The following files are provided to facilitate creation of your own 
> diff files of the XML.  
> 
> Initial XMLv3 created using XMLv2 as input:
>  https://www.rfc-editor.org/authors/rfc9324.original.v2v3.xml 
> 
> XMLv3 file that is a best effort to capture v3-related format updates 
> only: 
>  https://www.rfc-editor.org/authors/rfc9324.form.xml
> 
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>  https://www.rfc-editor.org/auth48/rfc9324
> 
> Please let us know if you have any questions.  
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC9324 (draft-ietf-sidrops-rov-no-rr-08)
> 
> Title            : RPKI-Based Policy Without Route Refresh
> Author(s)        : R. Bush, K. Patel, P. Smith, M. Tinka
> WG Chair(s)      : Keyur Patel, Chris Morrow
> 
> Area Director(s) : Warren Kumari, Robert Wilton
>