Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-07.txt

[Job Snijders <[e-mail]>]

On Thu, Oct 14, 2021 at 05:07:33PM +0200, Ties de Kock wrote:
> > 4.2.1:
> > 
> >       This field is an integer that is incremented (by 1) each time a
> >       new manifest is issued for a given publication point.  This field
> >       allows an RP to detect gaps in a sequence of published manifests.
> 
> I would really like it if we could leave this open and allow arbitrary
> increments. It's what is out there in the wild, and RPs can not check anything
> against manifestnumber either: Not all of them are guaranteed to be visible. 

But isn't that kind of the point though? To be able to detect whether an
RP saw all of them, because it is not guaranteed an RP will have
visibility into all of them?

> Strict incrementing counters are also a point of contention in implementations
> due to database locking on the parent CA.

Can you elaborate on this aspect?

> Existence/absense of manifests of a compliant CA is visible through the CRL. And
> it does not make behaviour of a sloppy CA invisible.
> 
> I would also like to revisit 4.2.2.
> 
> >   letter extension.  The extension MUST be one of those enumerated in
> >   the "RPKI Repository Naming Scheme" registry maintained by IANA
> >   [IANA-NAMING].
> 
> Since the content of the registry is dynamic, I think it would be good to
> clarify that encountering an unknown extension must not result in a failed fetch.
> If RPs become intolerant to new filenames using an extension not in the
> registry (for example .asa) would require a flag day. 
> 
> While reducing ambiguity in the results that RPs have when processing manifests
> is good I don't think rejecting unknown types is worth the downside.

A flag day can be avoided by putting the .asa object in its own
Publication Point: then the PP fails on older RPs (which is not a
problem), and works as expected on newer RPs.

Since for (for example) the .asa object type the early allocation
process is used, I think there is sufficient time between
'new idea' -> IANA registry update -> 'deployment in the wild'.

RP implementers need to stay up-to-date on what RPKI object types
currently exist, which seems reasonable. I think there is value in clear
guidance on what RPs should expect and not expect.

For example, rpki-client only attempts to sync currently known
filetypes, this hopefully limits the (potential) garbage RPs pull in:
https://github.com/openbsd/src/commit/22ca817fdd32d4cc08710821dad014cf18d1cd85

Kind regards,

Job