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 <[email protected]> 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 <[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
