Subject: Re: [sidr] New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt

From: Thomas King <[email-masked]>
Date: Tue, 5 Apr 2016 18:01:33 +0000

Hi Sriram,

thanks for your feedback. I comment inline.

> On 28 Mar 2016, at 22:14, Sriram, Kotikalapudi (Fed) <[email-masked]> wrote:
> 
> I read the draft. A few comments:
> 
> 1. RPKI validation refers to checking cryptographic integrity of the RPKI objects such as certs, ROAs, etc.
> What you intend to signal from RS to peers is prefix-origin validation results (RFC 6811).
> s/RPKI validation results/ prefix-origin validation results/g

Fixed.

> 
> 2. "Route-servers providing RPKI-based route
>   origin validation set the validation state according to the RPKI
>   validation result (see [I-D.ietf-sidr-rpki-validation-reconsidered])."  (in Section 2)
> 
> The reference cited here is incorrect. It should be RFC 6811.
> RFC 6811 defines the prefix-origin validation states and also provides the validation algorithm.

Fixed.

> 3. How do you signal that the RS did not perform validation on an update (for whatever reason).
> Is that implicitly conveyed when the "Prefix Origin Validation State Extended Community"
> is absent in the update forwarded to peers? May be it needs to be said in the draft.
> For instance, 'Not Found' should not be used as default value in the extended community.
> 'Did not perform validation' should not be equated to 'Not Found’.

I see your point.
I do not want to add another state as ietf-sidr-origin-validation-signaling defines only the ones used in this draft. I would like to be as close as possible to ietf-sidr-origin-validation-signaling as this draft just adds another use-case (route servers) to the concept.
If validation could not be performed by the route server no community should be set. The receiving peer should treat the update as if no prefix origin validation information was provided by the route server for this prefix ever. If this is okay with you I will add section covering this topic in the Recommendation section.

Best regards,
Thomas