Hi Warren, all,

I (co-author) agree that this was an oversight. I have no objections to the 
change.

However.. I haven't checked, but beware that current implementations might fail 
to parse the file if a "comment" member is added here, if they are (overly) 
strict. I expect that most will simply ignore this member. Perhaps it's wise 
that this is verified before finalising the errata.

Tim

> On 21 Aug 2022, at 17:57, Warren Kumari <[email protected]> wrote:
> 
> 
> Dear SIDROPS, at al,
> 
> I believe that this Errata is correct, and I intends to mark it Verified 
> unless I hear a clear objection by this Friday (August 26th).
> 
> W
> 
> 
> 
> On Wed, Aug 10, 2022 at 5:25 PM, Ben Maddison 
> <[email protected]> wrote:
> Adding sidrops@
> 
> On 08/10, RFC Errata System wrote:
> 
> The following errata report has been submitted for RFC8416, 
> "Simplified Local Internet Number Resource Management with the RPKI (SLURM)".
> 
> -------------------------------------- 
> You may review the report below and at: 
> https://www.rfc-editor.org/errata/eid7080
> 
> -------------------------------------- 
> Type: Technical 
> Reported by: Ben Maddison <[email protected]>
> 
> Section: 3.4.2
> 
> Original Text 
> ------------- 
> The above is expressed as a value of the "bgpsecAssertions" member, as an 
> array of zero or more objects. Each object MUST contain one each of all of 
> the following members:
> 
> o An "asn" member, whose value is a number.
> 
> o An "SKI" member, whose value is the Base64 encoding without trailing '=' 
> (Section 5 of [RFC4648]) of the certificate's Subject Key Identifier as 
> described in Section 4.8.2 of [RFC6487] (This is the value of the ASN.1 OCTET 
> STRING without the ASN.1 tag or length fields.)
> 
> o A "routerPublicKey" member, whose value is the Base64 encoding without 
> trailing '=' (Section 5 of [RFC4648]) of the equivalent to the 
> subjectPublicKeyInfo value of the router certificate's public key, as 
> described in [RFC8208]. This is the full ASN.1 DER encoding of the 
> subjectPublicKeyInfo, including the ASN.1 tag and length values of the 
> subjectPublicKeyInfo SEQUENCE.
> 
> Corrected Text 
> -------------- 
> The above is expressed as a value of the "bgpsecAssertions" member, as an 
> array of zero or more objects. Each object MUST contain one each of all of 
> the following members:
> 
> o An "asn" member, whose value is a number.
> 
> o An "SKI" member, whose value is the Base64 encoding without trailing '=' 
> (Section 5 of [RFC4648]) of the certificate's Subject Key Identifier as 
> described in Section 4.8.2 of [RFC6487] (This is the value of the ASN.1 OCTET 
> STRING without the ASN.1 tag or length fields.)
> 
> o A "routerPublicKey" member, whose value is the Base64 encoding without 
> trailing '=' (Section 5 of [RFC4648]) of the equivalent to the 
> subjectPublicKeyInfo value of the router certificate's public key, as 
> described in [RFC8208]. This is the full ASN.1 DER encoding of the 
> subjectPublicKeyInfo, including the ASN.1 tag and length values of the 
> subjectPublicKeyInfo SEQUENCE.
> 
> In addition, each object MAY contain one optional "comment" member, whose 
> value is a string.
> 
> Notes 
> ----- 
> The "comment" member is allowed to appear in every other structure defined by 
> the document, and was clearly intended to be allowed here too, since it 
> appears in the examples presented in sections 3.4.2 and 3.5
> 
> Instructions: 
> ------------- 
> This erratum is currently posted as "Reported". If necessary, please use 
> "Reply All" to discuss whether it should be verified or rejected. When a 
> decision is reached, the verifying party can log in to change the status and 
> edit the report, if necessary.
> 
> -------------------------------------- 
> RFC8416 (draft-ietf-sidr-slurm-08) 
> -------------------------------------- 
> Title : Simplified Local Internet Number Resource Management with the RPKI 
> (SLURM) Publication Date : August 2018 
> Author(s) : D. Ma, D. Mandelberg, T. Bruijnzeels Category : PROPOSED STANDARD 
> Source : Secure Inter-Domain Routing 
> Area : Routing 
> Stream : IETF 
> Verifying Party : IESG
> 
> _______________________________________________ 
> sidr mailing list 
> [email protected] 
> https://www.ietf.org/mailman/listinfo/sidr
> 
> 
> _______________________________________________
> sidr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sidr

_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to