Subject: [sidr] [Errata Verified] RFC8360 (5638)

From: RFC Errata System <[email-masked]>
Date: Wed, 13 Feb 2019 11:41:03 -0800 (PST)

The following errata report has been verified for RFC8360,
"Resource Public Key Infrastructure (RPKI) Validation Reconsidered". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5638

--------------------------------------
Status: Verified
Type: Technical

Reported by: Alberto Leiva Popper <[email-masked]>
Date Reported: 2019-02-13
Verified by: Warren Kumari (Ops AD) (IESG)

Section: 4.2.4.4

Original Text
-------------
   7.  Compute the VRS-IP and VRS-AS set values as indicated below:

       *  If the IP Address Delegation extension is present in
          certificate x and x=1, set the VRS-IP to the resources found
          in this extension.

       *  If the IP Address Delegation extension (...)

       *  If the IP Address Delegation extension (...)

       *  If the IP Address Delegation extension is present in
          certificate x and x=1, set the VRS-IP to the resources found
          in this extension.

       *  If the AS Identifier Delegation extension (...)

       *  If the AS Identifier Delegation extension (...)

Corrected Text
--------------
   7.  Compute the VRS-IP and VRS-AS set values as indicated below:

       *  If the IP Address Delegation extension is present in
          certificate x and x=1, set the VRS-IP to the resources found
          in this extension.

       *  If the IP Address Delegation extension (...)

       *  If the IP Address Delegation extension (...)

       *  If the AS Identifier Delegation extension is present in
          certificate x and x=1, set the VRS-AS to the resources found
          in this extension.

       *  If the AS Identifier Delegation extension (...)

       *  If the AS Identifier Delegation extension (...)

Notes
-----
There seems to be a copy-paste error.

There are two bullet points explaining the initialization of VRS-IP, and none explaining the initialization of VRS-AS.

All the evidence suggests that the two extensions (IP Address Delegation and AS Identifier Delegation) are meant to be handled similarly, so I believe that the last three bullet points are supposed to perfectly mirror the first three.

--------------------------------------
RFC8360 (draft-ietf-sidr-rpki-validation-reconsidered-10)
--------------------------------------
Title               : Resource Public Key Infrastructure (RPKI) Validation Reconsidered
Publication Date    : April 2018
Author(s)           : G. Huston, G. Michaelson, C. Martinez, T. Bruijnzeels, A. Newton, D. Shaw
Category            : PROPOSED STANDARD
Source              : Secure Inter-Domain Routing
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 13 Feb 2019 16:36:57 -0500

I’d be interested to hear from the implementer(s) of the validation-reconsidered RFC what impact there is in handling this change.

(I suspect little impact, if any, but it would be very good to hear it from the implementer(s).  Suspicions don’t count for much.)

—Sandy

> On Feb 13, 2019, at 2:41 PM, RFC Errata System <[email-masked]> wrote:
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 13 Feb 2019 16:43:40 -0500

Just in case there are people who do not know, Tim’s position has changed, the [email-masked] address is bouncing, and he has appeared in ietf mail lately as [email-masked].

So if you reply to my message or any of the RFC Errata System <[email-masked]> messages, you might want to replace the [email-masked] with the new address.

—Sandy

> On Feb 13, 2019, at 4:36 PM, Sandra Murphy <[email-masked]> wrote:
>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 14 Feb 2019 09:39:21 +0100

Hi all,

The errata is correct, this is a copy paste error.

There should be no impact on implementation, other than that if the implementation follows the original text strictly it will not work for ASNs on a trust anchor certificate, and if it's changed to follow the corrected text it will work. Mea culpa, I blame my copy/paste skills and replaying short term memory and my intent in proof reading my own bit of text here.

Tim

> On 13 Feb 2019, at 22:36, Sandra Murphy <[email-masked]> wrote:
>