Re: [auth48] AUTH48: RFC-to-be 9319 <draft-ietf-sidrops-rpkimaxlen-15> for

Rebecca VanRheenen <rvanrheenen@amsl.com> Thu, 29 September 2022 19:49 UTC

Return-Path: <rvanrheenen@amsl.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DF3C14F74B; Thu, 29 Sep 2022 12:49:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Level:
X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI5sk22nnEgf; Thu, 29 Sep 2022 12:49:32 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E0AC14F749; Thu, 29 Sep 2022 12:49:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 014DF425C152; Thu, 29 Sep 2022 12:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXSrCy4tx3Wi; Thu, 29 Sep 2022 12:49:31 -0700 (PDT)
Received: from [IPv6:2601:641:300:5fb0:4461:8ac7:9c8f:1ff6] (unknown [IPv6:2601:641:300:5fb0:4461:8ac7:9c8f:1ff6]) by c8a.amsl.com (Postfix) with ESMTPSA id 9C6E8425977A; Thu, 29 Sep 2022 12:49:31 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Rebecca VanRheenen <rvanrheenen@amsl.com>
In-Reply-To: <20220928085932.5x6k374wer6ulmyd@benm-laptop>
Date: Thu, 29 Sep 2022 12:49:30 -0700
Cc: RFC Editor <rfc-editor@rfc-editor.org>, sidrops-ads@ietf.org, sidrops-chairs@ietf.org, Chris Morrow <morrowc@ops-netman.net>, Warren Kumari <warren@kumari.net>, auth48archive@rfc-editor.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <88C3FBCA-95BF-4568-9F4D-8CBCC55A71EF@amsl.com>
References: <20220927053320.A4B3A4C956@rfcpa.amsl.com> <20220927134731.k5ly7e7yi2cnxhvb@benm-laptop> <559B18A8-CAA4-4855-82BF-7CCB183E6F91@amsl.com> <20220928085932.5x6k374wer6ulmyd@benm-laptop>
To: Ben Maddison <benm@workonline.africa>, yossigi@cs.huji.ac.il, goldbe@cs.bu.edu, kotikalapudi.sriram@nist.gov, Job Snijders <job@fastly.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/cr7fHNslFH5a08m37Ba3byd4hVI>
Subject: Re: [auth48] AUTH48: RFC-to-be 9319 <draft-ietf-sidrops-rpkimaxlen-15> for
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Sep 2022 19:49:36 -0000

Hi Ben,

We have updated the document. We would like to check with you on one more thing. RFC 6811 is frequently cited for "RPKI-based Route Origin Validation (ROV)” and “ROV” in this document; however, RFC 6811 doesn’t include the acronym ROV, though it does discuss “Origin Validation”. Will this cause any problems for readers? 

_______________

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

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

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

Diff files showing all changes:
  https://www.rfc-editor.org/authors/rfc9319-diff.html
  https://www.rfc-editor.org/authors/rfc9319-rfcdiff.html (side-by-side diff)
  https://www.rfc-editor.org/authors/rfc9319-alt-diff.html (shows changes where text was moved/deleted)

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

Thank you,

RFC Editor/rv



> On Sep 28, 2022, at 1:59 AM, Ben Maddison <benm@workonline.africa> wrote:
> 
> Hi Rebecca,
> 
> Thanks for the quick turn around!
> 
> On 09/27, Rebecca VanRheenen wrote:
>> Hi Ben,
>> 
>> Thank you for the updated XML file. We have posted updated output and
>> diff files (see links below). We also have a few followup
>> comments/questions:
>> 
>> 1) 
>> 
>>> <!-- [rfced] Will readers know what is meant by "the RPKI specification" in                                 
>>> these sentences?  Would adding a citation (perhaps to [RFC6480]) be                                         
>>> helpful?                                                                                                    
>>> 
>>> Original:                                                                                                   
>>>   Best current practices described in this document require no changes                                     
>>>   to the RPKI specification and will not increase the number of signed                                     
>>>   ROAs in the RPKI because ROAs already support lists of IP prefixes                                       
>>>   [RFC6482].                                                                                               
>>>   ...                                                                                                      
>>>   This practice requires no changes to the RPKI specification and need                                     
>>>   not increase the number of signed ROAs in the RPKI because ROAs                                          
>>>   already support lists of IP prefixes [RFC6482].                                                          
>>> 
>>> [BM]:                                                                                                       
>>>  Updated to "specifications" (plural).                                                                     
>>>  These specifications are spread over a considerable number of documents.                                  
>>>  I don't think that attempting to reference all of them is helpful.                                        
>>>  Similarly I think adding a reference to only RFC6480 may mis-lead the                                     
>>>  reader to beleive that this is the only one that is relevant.                                             
>>> -->
>> 
>> FYI - We also updated to "specifications" (plural) in the second sentence above. 
> 
> Thanks, I missed that.
> 
>> 2) 
>> 
>>> c) Please review the following forms and let us know if any updates are needed
>>> for consistency. Note that RFC 6811 is used as a citation for many of these
>>> instances.
>>> 
>>> RPKI-based origin validation
>>> RPKI origin validation
>>> RPKI-based route origin validation (ROV)
>>> RPKI-based route origin validation
>>> 
>>> [BM]:
>>>  RPKI-based Route Origin Validation (or ROV) is the correct term. I have
>>>  changed thoughout.
>> 
>> Would you like to use "RPKI-based Route Origin Validation (ROV)” for
>> the first instance in text and then use the shortened form "RPKI-based
>> ROV” thereafter? Or do you prefer the current arrangement? We note
>> that RFC 6811 is used as a citation for many of these and does not use
>> the acronym ROV, so that may be a factor in your decision here.
> 
> I went the route of expanding on first use, but on a per-section basis,
> in order that sections could easily be read in isolation without
> back-tracking.
> 
> However, on reflection, I think the acronym ROV is in wide enough use by
> the target audience that this is unnecessary. Please would you update to
> use just "ROV" after the first occurrence?
> 
>> 3) Should “ROV” in the current text below read "RPKI-based ROV”? Or is the current okay as is?
> [...]
> 
> Just "ROV" is fine. The acronym is widely used and well understood.
> Additionally, there is no such thing as "non-RPKI-based ROV" (or at
> least, nobody calls it that).
> 
> Cheers,
> 
> Ben