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

[Stephen Kent <[e-mail]>]

Ties,
> While reading the diff I thought it would be good to discuss this on 
> list:
>> 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.
> Strict incrementing counters are also a point of contention in implementations
> due to database locking on the parent CA.
>
> 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 made this change in response to a request from Ben Madison on 9/30. 
You did not comment on his suggestion then, or over the next 13 days. 
Why are arbitrary increments a "good thing?" Why are they out there now? 
Which CA's don't know how to count by 1?

The text does not require that an RP verify that the increment is 
monotonic, just that the new manifest has a nigher number than any 
previously-validated manifests from the same issuer. I don't see a need 
to change this.

>
> 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.

This text has not changed since version 4, posted in May of this year. 
It's way too late in this process to comment on this now, almost 6 
months later.

Steve