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