At 6:36 PM +0300 4/13/10, Yaron Sheffer wrote: >Here's a quick review of the numerous changes between -08 and -09. Let's get >these things resolved and move the doc to the IESG. > >I'm a bit uneasy with the use of "Notify error message" instead of the simpler >(and admittedly a bit vague) "notification". After all, these are not messages!
They are notifications that have meaning. The meaning makes them a message to the implementation. I think the new wording is better than just "notification", particularly because there are two types of Notify payloads. >2.4: For the sake of editing you eliminated a MUST NOT, I suggest to put it >back. The original text had: "An implementation MUST NOT continue sending on >any SA if some failure prevents it from receiving on all the associated SAs". As Tero pointed out, this 2119 language only applied to a teeny subset of implementers, and even then I do not think it is actionable by itself. The replacement language is better. >"Two expected attacks", but then "this attack" in the following sentence. I >think -08 had it right, and this should be singular. Also, the word "if" >slipped from the 2nd sentence. Good catch; fixed in the editorial-only -10. >"The preferred key size MUST be used as the length of SK_d, SK_pi, and SK_pr" >- this is a new MUST, are we all happy with it? It was strongly implied before. >2.21.2: "Extension documents may define new error notifications with these >semantics, but MUST NOT use them unless the peer has been shown to understand >them using the Vendor ID payload." The VID payload is one possibility, but >there may be others (e.g. an earlier status notification). So I suggest to add >"e.g. using the Vendor ID payload". Agree. >This text was removed from 2.23: "IKE MUST respond to the IP address and port >from which packets arrived". Is this requirement covered elsewhere? Yes, many places. >If you insist on changing NATs to NAT's in 2.23.1, you should make it NATs'. Agree. >In Sec. 4, I don't think we want to say "these are some of the features that >can be omitted", implying that there are more. Why not "these are features"? Agree. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
