Hi, One of the comment was the number of AF failure error. I think Med already answered this comment [1], see the question/answer below. If that does not address the question raised today, please describe how the number could be reduced.
Please also state whether we should use one status code for all AF failure error versus one status code per AF failure error. I think the WG preferred the latest alternative. Yours Daniel [1] https://mailarchive.ietf.org/arch/msg/ipsec/3DM_MzLmG-JYKGbA15siCkJbqV8 """ * Looking at the code points, I have the impression that with the current signaling, only the case where a single af is supported could be ambiguous. A host sending a request for IP4 and IP6 addresses, can easily deduce is which are the supported AF, except when the a single AF is supported. [Med] There are cases where both AFs are supported, but only an address/prefix can be returned. Which address is returned is policy-based. An initiator which does not get an address family type does not know whether it didn’t get the requested AF because (1) it is not supported or (2) because of a policy. The behavior of the initiator may change as function of this. For example, if it really needs an IPv4, but gets an IPv6 prefix, it will need to issue a request in which only INTERNAL_IP4_ADDRESS will be included and so on. """
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
