Sorry for the late reply ...
On Sun, 9 Mar 2014, Rob Austein wrote:
> > What happens if the ASNs are not in order (for some strange bug
> > reason)? It wouldn't harm the router?
>
> Point. So maybe caches MUST generate the canonical format but routers
> MAY skip checking to see whether the cache goofed this up?
>
Sounds good.
> > > Given that the rpki-rtr protocol requires duplicate elimination, we do
> > > need to perform such comparisons, so making them as simple as possible
> > > seems advisable.
> > >
> > I suppose this requires an update of the duplicate description
> > (similar text of Section 5.6 in Section 5.10, and update Section 11, no
> > 11).
>
> Or consolidate the discussion of duplicate PDUs somewhere else in the
> document, but yes, we need to nail that down.
>
I'm more in favor of consolidating.
Just to double check, because the term "duplicate" is not very clear
in this context - at least to me. In contrast to RFC 6810, in RFC
6810-bis a Router Key PDU contains a list of ASNs. The received PDU may
differ even though parts of the content are duplicates.
RFC 6810 says "identical to one it already has active", which means
that we are checking pieces of content. For example, the router receives
Router Key PDU with ASNs {10,20,30} and later the 'same' PDU but with
ASNs {10,20}. I would consider this as a duplicate. However, in this
case the ordering doesn't help to apply binary string comparison.
Thanks
matthias
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
