Dear John,
I think the report is correct, and it seems we already resolved it in the
-bis effort:
https://www.ietf.org/archive/id/draft-ietf-sidrops-rfc6482bis-03.html
Section 4.3.1 of the -bis contains the same sentence the errata report
proposed “The addresses field represents prefixes as a sequence of type
ROAIPAddress.”
The new description of ROAIPAddress also emphasises the “address” field
contains a single prefix.
It would be good to confirm with the reporter whether the description in
the -bis document matches their understanding of the ASN.1 notation.
If the -bis document as-is matches their understanding, it might mean that
multiple people independently observed a discrepancy in the original RFC.
:-)
Kind regards,
Job
Ps. There is an “addresses” field in one structure, and in another
structure an “address” field. :-)
On Wed, 31 May 2023 at 19:01, John Scudder <jgs=40juniper....@dmarc.ietf.org>
wrote:
> +sidrops
>
> The substance of the erratum is:
>
> - The sentence "The addresses field represents prefixes as a sequence of
> type ROAIPAddress” is added at the end of the first paragraph.
>
> This seems like an OK change although not a necessary one. If verified,
> it’d be as editorial Hold For Document Update. It doesn’t seem like it adds
> much to the spec, so I’m not inclined to verify it but could be talked into
> it.
>
> - In the second paragraph:
> - “a ROAIPAddress structure” -> “the ROAIPAddress structure” (“a”
> becomes “the”)
> - The ROAIPAddress structure changes from a sequence of IPAddress,
> to a single IPaddress (capitalization sic)
>
> The submitter says this change would align the prose description with the
> ASN.1. However, I don’t see that — I’m hardly an ASN.1 expert, but on the
> face of it, this (from Appendix A, also present in Section 3) looks like a
> sequence, not a singleton. The word “sequence” is right there, in ALL CAPS
> even.
>
> ROAIPAddress ::= SEQUENCE {
> address IPAddress,
> maxLength INTEGER OPTIONAL }
>
> As far as I can tell, this change is wrong and should be rejected.
>
> I would appreciate a second opinion from someone more conversant with the
> RFC and associated technology than I am before I reject it.
>
> —John
>
> > On May 26, 2023, at 2:49 PM, RFC Errata System <
> rfc-edi...@rfc-editor.org> wrote:
> >
> >
> > The following errata report has been submitted for RFC6482,
> > "A Profile for Route Origin Authorizations (ROAs)".
> >
> > --------------------------------------
> > You may review the report below and at:
> >
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7525__;!!NEt6yMaO-gk!GngQXDPNfl9uVTFUdN8h1LmYMMzXgBRp-NQTdsuPLKBo7KLOI4k9kFTNxaLsmnpNBXUj3GVFEfbA57aSAEPHFg$
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Sacha Boudjema <sachaboudj...@gmail.com>
>
> > Section: 3.3
> >
> > Original Text
> > -------------
> > Within the ROAIPAddressFamily structure, addressFamily contains the
> Address Family Identifier (AFI) of an IP address family. This
> specification only supports IPv4 and IPv6. Therefore, addressFamily MUST
> be either 0001 or 0002.
> >
> > Within a ROAIPAddress structure, the addresses field represents prefixes
> as a sequence of type IPAddress. (See [RFC3779] for more details). If
> present, the maxLength MUST be an integer ...
> >
> >
> > Corrected Text
> > --------------
> > Within the ROAIPAddressFamily structure, addressFamily contains the
> Address Family Identifier (AFI) of an IP address family. This
> specification only supports IPv4 and IPv6. Therefore, addressFamily MUST
> be either 0001 or 0002. The addresses field represents prefixes as a
> sequence of type ROAIPAddress.
> >
> > Within the ROAIPAddress structure, the address field represents an IPv4
> or IPv6 prefix of type IPaddress (See [RFC3779] for more details). If
> present, the maxLength MUST be an integer ...
> >
> > Notes
> > -----
> > Original text contradicts does not align with normative ASN.1 schema.
> >
> > 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.
> >
> > --------------------------------------
> > RFC6482 (draft-ietf-sidr-roa-format-12)
> > --------------------------------------
> > Title : A Profile for Route Origin Authorizations (ROAs)
> > Publication Date : February 2012
> > Author(s) : M. Lepinski, S. Kent, D. Kong
> > Category : PROPOSED STANDARD
> > Source : Secure Inter-Domain Routing
> > Area : Routing
> > Stream : IETF
> > Verifying Party : IESG
>
> _______________________________________________
> Sidrops mailing list
> sidr...@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
