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

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

> On 29 Jun 2023, at 13:34, Theo Buehler <[e-mail]> wrote:
> 
> 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 am also happy with reusing the OID and leaving the version at 0.
> 
> As an implementor of software targeting end users I don't want to (and
> won't) support anything but the final version.

Unfortunately, that is a luxury that I do not have.

As a developer of repository maintenance and CA software, for the reasons I
stated I can not avoid supporting the intersection of objects in the real worl
and what is upcoming.

I see two local maxima; version 1 (current, interoperable, tested objects) or a
new OID (no structure divergence at the same version). Re-using version 0 with a
different structure leads to complexity, especially since we must support both
simultaneously.

There are also a human factor at play in adding more churn. With the benefit of
hindsight, I would not have invested time in fully implementing this profile
change (I might have supported an MVP, ironically more likely to have mistakes
in version handling). This churn also weakens the case I made to others when
recommending them to move ASPA forward on their roadmaps; the profile is
unstable.