Re: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-profile-15.txt

[Ties de Kock <[e-mail]>]

Hi all,

> On 29 Jun 2023, at 12:26, Job Snijders <job=[e-mail]> wrote:
> 
> Dear Martin,
> 
> On Thu, Jun 29, 2023 at 11:58:10AM +0200, Martin Hoffmann wrote:
>> Job Snijders wrote:
>>> On Wed, Jun 28, 2023 at 05:33:07PM +0200, Martin Hoffmann wrote:
>>> 
>>>> While we are at it, I would like to again raise the suggestion to
>>>> not use a version 1 here but rather stick to 0 and use a different
>>>> content type OID. The older and newer definitions are not
>>>> compatible, so a new OID feels more appropriate than a version
>>>> change.  
>>> 
>>> I can see your argument, but I'm not sure there is clear consensus to
>>> request a fresh content-type OID, and there are counter-arguments too.
>>> 
>>> In the past the ASPA profile definition has been updated without
>>> cranking the version or content-type OID. Some argue we are in a phase
>>> of 'experimentation' (since the internet-draft isn't published as
>>> RFC), where some incompatibility with older revisions of the draft is
>>> to be expected and of no concern.
>> 
>> I’d be okay with leaving the version at 0 and using the current OID as
>> well. The old-format objects will fail to be decoded either way, so it
>> doesn’t really make a difference in practice. Depending on how the
>> parser works, they may be rejected even before you get to the version
>> check, too.
> 
> I agree, only low-level parsers would have a test/branch opportunity to
> jump to a different codepath based on the eContent version number. For
> example in rpki-client higher-level functions are used, causing
> old-format objects to be rejected before you get to the version check.
> https://github.com/openbsd/src/blob/2b5ea97fcaa542de6fb9316d0e7e06767bdf24cd/usr.sbin/rpki-client/aspa.c#L49-L62

But you could test against multiple formats there.

Recall that extremely limited tooling is available for DER in some languages.
> 
>> I’m a bit worried with having version 1 in a newly published standard.
>> It’ll be the only one that does that and it is very easy to miss
>> because it really is just a single digit in the text below the
>> grammar.
> 
> A (somewhat weak) argument could be made that there is some educational
> value using this new object as an opportunity to 'practise' an eContent
> version bump, but since the old-format and new-format structure differ
> so much, the excercise of bumping the eContent version seems of limited
> value.
> 
>> Ask me how I know ...
> 
> hah! :-) If it's any consolation, you weren't the only one.
> 
> I think we are blessed that multiple people are now independently
> producing and validating objects to help each other cross-check.
> 
> Based on the feedback so far (offlist and onlist) I'm inclined to update
> the internet-draft to require the eContent version to 0, and continue to
> use the current OID.

I strongly disagree with reverting the version to 0 w/ the same OID.

We have interoperability and test objects with version 1 at the moment.
Reverting causes churn without clear benefit, and will cause more implementation
complexity for implementations that need to consider the objects that are
effectively deployed in the wild.

More expressions of support of reverting to verion-0-with-differing-schema
on-list would help clarify how strong this support is.

Kind regards,
Ties