I have got no objection to this erratum as the co author of RFC8416. Thanks go to Ben for catching this.
And this update will not affect RPSTIR2 as we check it. Anyway, I think this discussion will help to update SLURM in support of ASPA in next version as Tim mentioned. Di > 2022年8月22日 16:47，Ties de Kock <[email protected]> 写道： > > Hi Tim, all, > >> On 22 Aug 2022, at 10:29, Tim Bruijnzeels <[email protected]> wrote: >> >> 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. > > I checked two implementations. The (archived) RIPE NCC validator accepts a > comment field in bgpsecAssertions. StayRTR does not parse the bgpsecAssertions > structure and I expect it to ignore additional attributes. > > However, if there are any compliant implementations, following section 3.1, > they would not accept a file that incorporates that follows the change > proposed > in this erratum: > > > ... An RP MUST consider any deviations from the specifications to > > be errors. > > I think we need to keep this in mind when discussing this erratum. > > Kind regards, > Ties >> >> 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 > > _______________________________________________ > Sidrops mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidrops _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
