In the sectioon 2.9 the "SHOULD" requirement was removed for the very specific traffic selector as fist traffic selector.
I think that "SHOULD" requirement needs to be kept, as it affects interoperability, as if other end does not include that triggering packet then certain policies cannot interoperate. Also in the interops we have seen implementations who could not interoperate at all if sender end included triggering packet (I do not know if the failure to create Child SA was because the traffic selector containing port selectors, or whether it was because there were multiple traffic selectors). If there is "SHOULD" level requirement for that, then we can at least point the other vendors to that and say, that as we SHOULD be sending that triggering packet, then you also needs to be able to cope with it... Old text was: To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first traffic selector in each of TSi and TSr a very specific traffic selector including the addresses in the packet triggering the request. new text in draft-ietf-ipsecme-ikev2bis-07.txt is: If the initiator requests an SA because it wants to send a data packet, including the specific addresses in the packet triggering the request in the first traffic selector in both TSi and TSr enables the responder to choose the appropriate range. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
