Hi Paul, > 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.
That would make sending these notifies dependent on the content of request. So, the tradeoff is whether saving eight bytes justifies complication of state machine. Regards, Valery. > 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
