Hi Daniel,
it was me who made this comment. The current number of notifications seems to be excessive for the task. Not that I'm all that greedy (also Occam razor has been sitting sitting in my mind), but the current design makes implementation more complex then it could be. You have a separate notification for each possible situation. That makes the responder think before returning back a "proper" answer. But actually, most of these different notifications return exactly the same two bit of information - which address families are supported by the server (or allowed by its policy). Moreover, this two bits of information are mostly static! So, what design I would have preferred? Two notifications are enough - SUPPORTED_AF (containing some data indicating which AFs are supported) and SINGLE_AF_SUPPORTED. If you don't like notification data, then three notifications are enough - IP4_AF_SUPPORTED, IP6_AF_SUPPORTED and SINGLE_AF_SUPPORTED. Note that I changed meaning from negative to positive, that is more appropriate for status type notification and also makes it possible to easy extend protocol in case a new fictional AF appears in future. In this case the server can make an assignment of the IP addresses decoupled from the returned notifications, which in this case become almost static: you can _always_ return corresponding IP*_AF_SUPPORTED (either one of them or both) regardless of whether you assigned IPs or not and which AF you assigned. That makes server implementation simpler. The only case when server need to return more is the 4th case, when it would in addition send SINGLE_AF_SUPPORTED (actually it is not all that needed and the client can easily deduce it, but let's make his life simpler). This is mostly ad hoc design, it can definitely be discussed. Regards, Valery. 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
