I would prefer no notify if the request was fulfilled and to only send a notify if a request could not be fulfilled. Since clients can ask for both that should cover things. If a client isn’t asking for ipvX, I see no need to answer that ipvX is supported too.
Paul Sent from mobile device > On Apr 17, 2019, at 03:48, Valery Smyslov <[email protected]> wrote: > > Hi, > > I was thinking of another alternative design (well, it's a small modification > of a current one). Instead of defining IP4_ONLY_ALLOWED and IP6_ONLY_ALLOWED, > define IP4_ALLOWED and IP6_ALLOWED. The semantics would be a positive > assertion that this particular AF allowed, without any concerns with the > other AF. > > In this case, the behavior would be as follows: > > Requested @Init Supported @Resp Assigned Returned Notification > > IPv4 IPv6 None IP6_ALLOWED > > IPv6 IPv6 IPv6 IP6_ALLOWED > > IPv6 IPv4 None IP4_ALLOWED > > IPv4 IPv4 IPv4 IP4_ALLOWED > > IPv4 and IPv6 IPv6 IPv6 IP6_ALLOWED > > IPv4 and IPv6 IPv4 IPv4 IP4_ALLOWED > > IPv4 and IPv6 IPv6 or IPv4 IPv6 or IPv4 IP4_ALLOWED, > (Policy-based) IP6_ALLOWED > > IPv4 and IPv6 IPv6 and IPv4 IPv6 and IPv4 IP4_ALLOWED, > IP6_ALLOWED > > An (mostly theoretical) advantage of this design is that if some new AF > appears > (well, I understand that it's unlikely in the foreseen future, but who knows), > the design will work w/o changes, we only need to define a new <AF>_ALLOWED > notification. > > Regards, > Valery. > > >> In the Prague meeting we had two options how to send information what >> kind of address families are supported [1]: >> >> 1) IP6_ONLY_ALLOWED and IP4_ONLY_ALLOWED status notifications which >> are sent whenever only one address family is supported. I.e., if >> only one address family is supported, then IP*_ONLY_ALLOWED is >> sent. If both address families are supported, then no status code >> is sent. This is what current draft proposes. >> >> 2) ADDITINAL_ADDRESS_FAMILY_POSSIBLE status notification which is used >> when other address family than currently returned could also be >> used. I.e., if no address was assigned, then this status >> notification tells that trying with other address family works, and >> if address was assigned from one address family this tells that >> another request with another address family can also work. >> >> In the meeting we did not have clear concensus [2] on which of them >> are better. The option 2 is closer to what we currently have in >> RFC7296 for ADDITIONAL_TS_POSSIBLE. >> >> Both of the options seems to work, and I think people think the >> differences are so small, that they do not care. So unless people >> object soon, I think we will keep whatever is in the draft, as I >> seemed to be only one who thought the other option would be clearer. >> >> [1] See slides 6 and 7 of >> >> https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-chair-slides-04 >> [2] https://datatracker.ietf.org/doc/minutes-104-ipsecme/ >> -- >> [email protected] >> >> _______________________________________________ >> IPsec mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
