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 <[email protected]> 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... > -- > [email protected] > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
