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

[Job Snijders <[e-mail]>]

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

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

Kind regards,

Job