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

[Job Snijders <[e-mail]>]

Dear Murray,

Thank you for the review!

On Tue, Feb 01, 2022 at 10:42:36PM -0800, Murray Kucherawy via Datatracker wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> The response to question 7 of the shepherd writeup doesn't really answer the
> question being asked.

I searched through the archives and found this 2011 message:
https://mailarchive.ietf.org/arch/msg/sidr/qIH6oAeWpeHzYmE783oK-rKi6ck/

    "No IPR declarations have been submitted directly on this I-D."

In the interest of progressing this document it seems prudent to obtain
stronger assurances that the -bis document does not introduce new IPR concerns.

Through the [e-mail] mailing list I'll publicly request whether the
authors know of any IPR related to this document, once all four responded I'll
circle back to this thread to tidy up that aspect. Stay tuned.

> Also, please tidy up the stuff identified in the answer to question 11.

Thanks for pointing this out. I've resolved all nits.

> Section 4.2.1:
> 
> * "... this field is more recent any previously-generated ..." --
> s/recent/recent than/
> 
> Appendix B:
> 
> * Since this is obsoleting, not updating, RFC 6486, I think this is more like
> "Changes Since RFC 6486".

Thanks, these two have been changed.

A diff is viewable here, or below as patch(1) formatted changeset:

    https://github.com/job/draft-ietf-sidrops-6486bis/commit/f9663bd4f24046fab9e0bb361259af7c42c39cc6

Kind regards,

Job

-- 

commit f9663bd4f24046fab9e0bb361259af7c42c39cc6
Author: Job Snijders <[e-mail]>
Date:   Thu Feb 3 14:47:42 2022 +0000

    Incorporate feedback from Murray Kucherawy
    
    https://mailarchive.ietf.org/arch/msg/sidrops/xWHUPInYdZhNKaQe7RF6RAInNI0/

diff --git draft-ietf-sidrops-6486bis.xml draft-ietf-sidrops-6486bis.xml
index f59546d..dac779f 100644
--- draft-ietf-sidrops-6486bis.xml
+++ draft-ietf-sidrops-6486bis.xml
@@ -7,17 +7,14 @@
 <!ENTITY RFC6485 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6485.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 RFC6493 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6493.xml">
 <!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
-<!ENTITY RFC8209 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8209.xml">
-<!ENTITY RFC8488 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8488.xml">
 <!ENTITY RFC3370 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3370.xml">
 <!ENTITY RFC3779 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3779.xml">
 <!ENTITY RFC6480 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6480.xml">
 <!ENTITY RFC6486 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6486.xml">
 <!ENTITY RFC6489 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6489.xml">
 ]>
-<rfc submissionType="IETF" docName="draft-ietf-sidrops-6486bis-09" category="std" obsoletes="6486" ipr="trust200902">
+<rfc submissionType="IETF" docName="draft-ietf-sidrops-6486bis-09" category="std" obsoletes="6486" ipr="trust200902" consensus="true">
 	<!-- Generated by id2xml 1.5.0 on 2021-05-31T14:49:22Z -->
 	<?rfc strict="yes"?>
 	<?rfc compact="yes"?>
@@ -108,7 +105,7 @@
    are similar to those for CRLs.  The syntax of the manifest payload
    differs from CRLs, since RPKI repositories contain objects not
    covered by CRLs, e.g., digitally signed objects, such as Route
-   Origination Authorizations (ROAs).</t>
+   Origination Authorizations (ROAs) <xref target="RFC6482"/>.</t>
 
    <t>This document obsoletes <xref target="RFC6486"/>.</t>
 
@@ -252,7 +249,7 @@
 	<vspace blankLines="0"/>
       This field contains the time when the manifest was created.
       This field has the same format constraints as specified in <xref target="RFC5280"/> for the CRL field of the same name.
-      The issuer MUST ensure that the value of this field is more recent any previously-generated Manifest. 
+      The issuer MUST ensure that the value of this field is more recent than any previously-generated Manifest.
       Each RP MUST verify that this field value is greater (more recent) than the most recent Manifest it has validated.
 	</t>
 
@@ -633,7 +630,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, and Adianto Wibisono for their helpful review of this document.</t>
+   The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, Adianto Wibisono, and Murray Kucherawy for their helpful review of this document.</t>
 	</section>
 
 	</middle>
@@ -657,10 +654,7 @@
 	&RFC6486;
 	&RFC6487;
 	&RFC6488;
-	&RFC6493;
 	&RFC8174;
-	&RFC8209;
-	&RFC8488;
     
     <reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690-199511-S!Cor1">
         <front>
@@ -684,51 +678,51 @@
 ]]></artwork>
     </figure>
     <figure><artwork><![CDATA[
-        DEFINITIONS EXPLICIT TAGS ::=
-           BEGIN
-           
-           -- EXPORTS ALL --
+    DEFINITIONS EXPLICIT TAGS ::=
+       BEGIN
+       
+       -- EXPORTS ALL --
 
-           IMPORTS
+       IMPORTS
 
-             CONTENT-TYPE
-             FROM CryptographicMessageSyntax-2010 -- in [RFC6268]
-               { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
-                 pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;
+         CONTENT-TYPE
+         FROM CryptographicMessageSyntax-2010 -- in [RFC6268]
+           { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+             pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;
 
-           -- Manifest Content Type
+       -- Manifest Content Type
 
-           ct-rpkiManifest CONTENT-TYPE ::=
-               { TYPE Manifest IDENTIFIED BY id-ct-rpkiManifest }
+       ct-rpkiManifest CONTENT-TYPE ::=
+           { TYPE Manifest IDENTIFIED BY id-ct-rpkiManifest }
 
-           id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
-               us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
+       id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+           us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
 
-           id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
+       id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
 
-           id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }
+       id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }
 
-           Manifest ::= SEQUENCE {
-              version        [0] INTEGER DEFAULT 0,
-              manifestNumber     INTEGER (0..MAX),
-              thisUpdate         GeneralizedTime,
-              nextUpdate         GeneralizedTime,
-              fileHashAlg        OBJECT IDENTIFIER,
-              fileList           SEQUENCE SIZE (0..MAX) OF FileAndHash
-              }
+       Manifest ::= SEQUENCE {
+          version        [0] INTEGER DEFAULT 0,
+          manifestNumber     INTEGER (0..MAX),
+          thisUpdate         GeneralizedTime,
+          nextUpdate         GeneralizedTime,
+          fileHashAlg        OBJECT IDENTIFIER,
+          fileList           SEQUENCE SIZE (0..MAX) OF FileAndHash
+          }
 
-           FileAndHash ::= SEQUENCE {
-              file  IA5String,
-              hash  BIT STRING
-              }
+       FileAndHash ::= SEQUENCE {
+          file  IA5String,
+          hash  BIT STRING
+          }
 
-           END
+       END
 
 ]]></artwork>
     </figure>
     </section>
 
-    <section title="Changes to RFC 6486" anchor="sect-b">
+    <section title="Changes since RFC 6486" anchor="sect-b">
     <t>
        In 2019 it came to light that multiple Relying Party implementations
        were in a vulnerable position, possibly due to perceived ambiguity in