Re: [Sidrops] Lars Eggert's No Objection on draft-ietf-sidrops-6486bis-09: (with COMMENT)

[Job Snijders <[e-mail]>]

Dear Lars,

Many thanks for your review of this document!

On Thu, Feb 03, 2022 at 02:43:17AM -0800, Lars Eggert via Datatracker wrote:
> Using lowercase "not" together with an uppercase RFC2119 keyword is not
> acceptable usage. Found: "MUST not"

This was addressed after Francesca's feedback, see
https://mailarchive.ietf.org/arch/msg/sidrops/NzCcNzcN46FD7RgV3D5ULMnEhxs/
for resolution

> Found terminology that should be reviewed for inclusivity; see
> https://www.rfc-editor.org/part2/#inclusive_language for background and more
> guidance:
> 
>  * Term "man"; alternatives might be "individual", "people", "person".

This was addressed after Roman's feedback, see
https://mailarchive.ietf.org/arch/msg/sidrops/4rlNabm2w9r6vD3r-2oY5ezr6Fs/
for resolution

> -------------------------------------------------------------------------------
> All comments below are about very minor potential issues that you may choose to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
> will likely be some false positives. There is no need to let me know what you
> did with these suggestions.
> 
> Section 5.2. , paragraph 5, nit:
> > ion point to effect this operation. Thus the term "fetch" refers to an operat
> >                                     ^^^^
> A comma may be missing after the conjunctive/linking adverb "Thus".

My mastering of the English language is insufficient. I propose to leave
this up to the RFC Editor (I will request the RFC Editor to pay
attention to this sentence)

> Section 11.1. , paragraph 11, nit:
> > Appendix B. Changes to RFC 6486 In 2019 it came to light that multiple Relyin
> >                                    ^^^^
> A comma is probably missing here.

Added.

> Uncited references: [RFC6493], [RFC6482], [RFC8209], and [RFC8488].

This was fixed through
https://mailarchive.ietf.org/arch/msg/sidrops/EYxcUtZLF7go2UBnOoOXqwn6bRY/

> Reference [RFC6485] to RFC6485, which was obsoleted by RFC7935 (this may be on
> purpose).

I have no reason to believe this was done on purpose. Updated!

Full overview of the diff based on your feedback: https://github.com/job/draft-ietf-sidrops-6486bis/commit/f862be520c37c956e839f1770371d799d8fd8295

Kind regards,

Job



commit f862be520c37c956e839f1770371d799d8fd8295
Author: Job Snijders <[e-mail]>
Date:   Thu Feb 3 16:43:40 2022 +0000

    Update reference and add missing comma
    
    Feedback from Lars Eggert
    
    https://mailarchive.ietf.org/arch/msg/sidrops/HeKoTC1AKAOGLM7CtBKx-1allSw/

diff --git draft-ietf-sidrops-6486bis.xml draft-ietf-sidrops-6486bis.xml
index 97db9fd..c1268a7 100644
--- draft-ietf-sidrops-6486bis.xml
+++ draft-ietf-sidrops-6486bis.xml
@@ -4,7 +4,7 @@
 <!ENTITY RFC5280 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
 <!ENTITY RFC6481 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6481.xml">
 <!ENTITY RFC6482 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6482.xml">
-<!ENTITY RFC6485 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6485.xml">
+<!ENTITY RFC7935 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7935.xml">
 <!ENTITY RFC6487 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6487.xml">
 <!ENTITY RFC6488 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6488.xml">
 <!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
@@ -261,7 +261,7 @@
 	This field contains the OID of the hash algorithm used to hash the
       files that the authority has placed into the repository.  The hash
       algorithm used MUST conform to the RPKI Algorithms and Key Size
-      Profile specification <xref target="RFC6485"/>.
+      Profile specification <xref target="RFC7935"/>.
 	</t>
 
 	<t hangText="fileList:">
@@ -609,7 +609,7 @@
 	<section title="Acknowledgements" anchor="sect-10"><t>
    The authors would like to acknowledge the contributions from George Michelson and Randy Bush in the preparation of the manifest specification.
    Additionally, the authors would like to thank Mark Reynolds and Christopher Small for assistance in clarifying manifest validation and RP behavior.
-   The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, Adianto Wibisono, Murray Kucherawy, Francesca Palombini, and Roman Danyliw for their helpful review of this document.</t>
+   The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, Adianto Wibisono, Murray Kucherawy, Francesca Palombini, Roman Danyliw, and Lars Eggert for their helpful review of this document.</t>
 	</section>
 
 	</middle>
@@ -629,7 +629,7 @@
 	&RFC5280;
 	&RFC6481;
 	&RFC6482;
-	&RFC6485;
+	&RFC7935;
 	&RFC6486;
 	&RFC6487;
 	&RFC6488;
@@ -703,7 +703,7 @@
 
     <section title="Changes since RFC 6486" anchor="sect-b">
     <t>
-       In 2019 it came to light that multiple Relying Party implementations
+       In 2019, it came to light that multiple Relying Party implementations
        were in a vulnerable position, possibly due to perceived ambiguity in
        the original <xref target="RFC6486"/> specification.
        This document attempts to clarify the innovative concept and application