On Sun, July 12, 2009 1:33 pm, Paul Hoffman wrote: >>But it still seems wrong to have two different documents defining the >> same >>curve differently, even if they are uncorrelated Informational RFCs. > > Again: RFC 5114 does not "define" those three curves. The IANA registry, > <http://www.iana.org/assignments/ikev2-parameters>, defines them, and has > the definition pointing to RFC 4753.
No, the IANA registry defines a magic number one uses to refer to the parameters of the curve which are actually defined in an RFC. And while FFFFFFFF 00000001 00000000 00000000 00000000 FFFFFFFF FFFFFFFF FFFFFFFC may equal -3 in this wonderful prime modulus group it causes a double- or triple-take when implementing the group referred to by the IANA registry that is defined in this RFC. There are 2 RFCs that define the same parameters of group 19 differently even if mathematically they are not different. And actually I think defining the curve ala RFC5114 is better since a prime finite field is defined as [0, 1, ..., p-1] and "-3" is not in that set. >> Can you elaborate on why you don't want to "ask the 4753bis authors to >>significantly expand their document in a way that they didn't intend in >>the original"? > > Yes. The current rfc4752bis, which is in IETF Last Call, has a very clear > focus, namely to fix the error that started this thread. Asking them to > also take on work that is unrelated to that focus is inappropriate. If > they wanted to do that, they could have done so before IETF Last Call. When "Last Call" is announced it doesn't mean you can't order a drink anymore, it means this is your last chance to order a drink before it's too late. For I-Ds, comments post publication are "too late" and it hasn't been published yet so it's not too late to ask the authors to change their draft. Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
