Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00

[David Schinazi <[e-mail]>]

Based on these arguments, I agree that a new value (5) is preferable to 0.

David


> On Feb 9, 2017, at 08:57, Paul Wouters <[e-mail]> wrote:
> 
> Yes I forgot to reply. I strongly object to assigning 0 for real values. It should be left for implementations to detect a value has not been set.
> 
> Paul
> 
> Sent from my iPhone
> 
>> On Feb 9, 2017, at 11:12, Tommy Pauly <[e-mail]> wrote:
>> 
>> Thanks for sending out the corrected draft name, Tero. I think this draft is in good shape in general and we should move forward with it.
>> 
>> The only thing that seems to need ironing out is the specific IANA hash value. I can see the argument either way: as the draft points out, 0 makes sense for the Identity hash, since it can be viewed as "no hash at all". However, I agree with your point that 0 may often be used in code to indicate an uninitialized value. I would be concerned if existing implementations flagged 0 as an error, here, as well.
>> 
>> I think it would make sense to do a quick poll of the WG to get some consensus on this. At this point, I'm mildly in favor of a new value (5).
>> 
>> Thanks,
>> Tommy
>> 
>>> On Feb 9, 2017, at 4:40 AM, Tero Kivinen <[e-mail]> wrote:
>>> 
>>> Ah I noticed that my last call email had wrong draft name in the
>>> subject line and in the link. The correct draft name is of course
>>> draft-ietf-ipsecme-eddsa-00 not *-nir-* version.
>>> 
>>> David Schinazi writes:
>>>> I've reviewed this draft. I support it and believe it is ready to move forward
>>>> towards becoming a standards-track RFC. Also, would it make sense to ask
>>>> IANA for early assignment of the code point? Using 0 sounds reasonable to me.
>>> 
>>> As this is expert review registry there is no need to ask for early
>>> allocation, the normal process is just to fill in the IANA general
>>> request for assignments, which then goes to the IANA and they will
>>> then send it to the expert (me) for verification.
>>> 
>>> If normal number (other than 0) would be given out, then I would just
>>> say yes, but allocating 0, which in registry is marked as:
>>> 
>>>   0    Reserved    [RFC7427]
>>> 
>>> and is not part of the :
>>> 
>>>   5-1023    Unassigned
>>> 
>>> range, then I would be bit more hesitant to give it out, and would
>>> most likely want to poll the WG and list before making decision.
>>> 
>>> I actually myself think it would be better to just allocate next free
>>> number from the unassigned space, and keep the value 0 as reserved...
>>> 
>>> For example we do not use value 0 of Encryption Algorithms transform
>>> to mean ENCR_NULL, we do have separate number allocated for it. On the
>>> other hand we do have value 0 meaning NONE in the Integrity algorithm
>>> transform ID table and for diffie hellman values, but there the
>>> meaning is bit different, it means there is no value for that id, here
>>> it would be meaning that there is this identity function version of
>>> the hash function. 
>>> 
>>> As an expert and as a implementor I think I would prefer next free
>>> number over 0... Quite commonly in the code we use value 0 as meaning,
>>> we have not yet received anything, or we have not yet initialized this
>>> field, and having separate value for identity function might make
>>> things easier. But if others have good reasons why the value 0 is
>>> better, feel free to tell me...
>>> -- 
>>> [e-mail]
>>> 
>>> _______________________________________________
>>> IPsec mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ipsec
>> 
>> _______________________________________________
>> IPsec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ipsec
>