John:
I think that the errata author is talking about:
RouteOriginAttestation ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
asID ASID,
ipAddrBlocks SEQUENCE (SIZE(1..MAX)) OF ROAIPAddressFamily }
ASID ::= INTEGER
ROAIPAddressFamily ::= SEQUENCE {
addressFamily OCTET STRING (SIZE (2..3)),
addresses SEQUENCE (SIZE (1..MAX)) OF ROAIPAddress }
That is, ipAddrBlocks contains one or more ROAIPAddressFamily structures.
I do not think that any implementers have been confused, so I think Hold for
Document Update is the right way forward.
Russ
> On May 31, 2023, at 12:21 PM, John Scudder <[email protected]>
> 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 <[email protected]>
>> 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 <[email protected]>
>>
>> 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
>
> _______________________________________________
> sidr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
