Yoav Nir writes: > Issue #147 - Allowing limited retransmission of one-way IKE messages > ==================================================================== > Either in 2.1 or in 1.5 we should say something about allowing > limited retransmission of the rare one-way IKE messages, for > reliability. > > How about the following new paragraph at the end of 2.1: > The retransmission policy for one-way messages is somewhat different > from that of regular messages. Since no acknowledgement is ever sent, > there is no reason to gratuitously retransmit. Since all these > messages are errors, it makes sense to send them only once per > "offending" packet, and retransmit is further offending packets are > received. Still, it makes sense to limit retransmissions of such > error messages.
That text looks good. > Issue #149 - Use of "SA" and "SA pair" > ====================================== > 2.8: "The responder can be assured that the initiator is prepared to > receive messages on an SA if either (1) it has received a > cryptographically valid message on the new SA." this should really > be "...on the new SA's dual SA" (or better wording thereof) since > there's a pair of SAs, and we are determining the state of one based > on the other. In general I think we are using the terms SA and SA > Pair interchangeably, which is rather confusing. > > The term "dual SA" does not appear anywhere in the draft. OTOH > section 1.4.1 has the term "half of an SA pair". How about > The responder can be assured that the initiator is prepared to > receive messages on an SA if either (1) it has received a > cryptographically valid message on the other half of the SA > pair, or (2) ... "Other half" is ok, as would be leaving this text as it was, as I do not think there is that big confusion about the issue. > Issue #167 - IPv6 config attributes > =================================== > 3.15.1: "With IPv6, a requestor MAY supply the low-order address > octets it wants to use." This means to me that you *don't* provide > all 16 octets. But according to the table, the field is a > fixed-length 16 octets! > > Tero suggested we leave the text as-is, and live with the > implication that you send the full 128 bits, with only the suffix > meaningful (or the prefix being a suggestion). I'm fine with that, > so unless someone objects... Yes. If someone wants some better text to explain situation better, then is better to provide text... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
