Re: [Sidrops] Making ASPA AFI-Agnostic - coordination

[Job Snijders <[e-mail]>]

On Thu, Jun 08, 2023 at 06:12:10PM +0200, Martin Hoffmann wrote:
> Russ Housley wrote:
> > 
> > In CMS, the version number indicates which alternatives are possible
> > in some CHOICEs.  The point is to ensure that the ASN,1 decode
> > operation will work if you recognize the version number.
> 
> But, crucially, the overall structure remains the same. The new version
> of the draft changes the structure of the ProviderASSet which I think
> warrants to treat this as an entirely new definition and use a new
> content type OID.

Another relevant question is whether we want to have a 'grace period' in
which both formats are valid. I myself would prefer to make this is a
'hard cut', simply a breaking change to avoid the complications of
supporting both profiles in my RP implementation.

As far as I know there is only one ASPA verifying deployment (YYCIX),
and the few already-existing ASPA objects can probably easily be updated
through a software update.

If the group accepts it as a 'breaking change' and commits to work to
migrate the tiny ASPA ecosystem in the span of a few weeks, I see less
of a need to get a new content-type OID. Technically if 'breaking
change' is the choosen path forward, there wouldn't even be a need to
bump the version of contained in the eContent.

However, bumping the version contained in the eContent is be a novelty
in the RPKI ecosystem, so keep things as-is (profile-15) might have some
value as a learning experience for this community.

In this situation I suspect there aren't objectively right or wrong
choices, but in the interest of time we should converge and agree rather
sooner than later on one of the options.

For previous ASPA profile changes no new OID were requested.

Kind regards,

Job