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

[Russ Housley <[e-mail]>]

> On Oct 6, 2021, at 2:52 AM, Tim Bruijnzeels <[e-mail]> wrote:
> 
> Russ (and Ben):
> 
>> On 1 Oct 2021, at 21:30, Russ Housley <[e-mail]> wrote:
>> 
>> 
>> 
>>> On Oct 1, 2021, at 2:47 AM, Tim Bruijnzeels <[e-mail]> wrote:
>>> 
>>> Hi,
>>> 
>>> I saw this:
>>> 
>>>> On 30 Sep 2021, at 23:11, Russ Housley <[e-mail]> wrote:
>>>> 
>>>>   version        [0] INTEGER DEFAULT 0,
>>> 
>>> This is how it was done, and also what the e.g. the ROA profile uses.
>>> 
>>> However, reading the ASPA profile I came across another way, like:
>>> 
>>>   version        [0] VERSION DEFAULT v0,
>>> 
>>>   VERSION ::= INTEGER { v0(0) }
>>> 
>>> 
>>> This does not change the profile really afaik, but I believe this
>>> explicitly limits the available options of 'version' to just 'v0',
>>> i.e. an INTEGER with value 0. So, this may be a bit better in that
>>> regard.
>> 
>> 
>> Tim:
>> 
>> These produce the same bits on the wire.  The difference is that the various versions have names ifor each of the integer version values. In that case, the name is "v0".
>> 
>> When v1 gets defined, the definition needs to be expanded to:
>> 
>>  VERSION ::= INTEGER { v0(0), v1(1) }
>> 
>> For example, RFC 5652 has:
>> 
>> CMSVersion ::= INTEGER  { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }
> 
> Indeed, I did not mean to suggest that the encoding would be different, just that the set is limited.
> 
> So, if there is a version change it would have to be expanded, but presumably other properties would change as well - e.g. we would no longer insist on the value being 0 in validation. So I am not sure that this is an issue.
> 
> In any case, I do not have any preference for one or the other but I noticed that it's different between manifests and the proposed ASPA profile. Plain 'INTEGER' is perfectly fine by me as well, but that does make me wonder whether the ASPA profile should just use that as well.
> 
> Tim


This is just a matter of style I think.

Russ