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

From: Lars Eggert via Datatracker <[email-masked]>
Date: Thu, 03 Feb 2022 02:43:17 -0800

Lars Eggert has entered the following ballot position for
draft-ietf-sidrops-6486bis-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Using lowercase "not" together with an uppercase RFC2119 keyword is not
acceptable usage. Found: "MUST not"

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

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

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.

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

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

---

From: Job Snijders <[email-masked]>
Date: Thu, 3 Feb 2022 17:45:35 +0100

Dear Lars,

Many thanks for your review of this document!

> acceptable usage. Found: "MUST not"

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

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

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)

> 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

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 <[email-masked]>
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