+1, there seems a problem to solve, so I support the adoption. The question I would raise are: * Do we want to add code and update IKEv2 or do we want to define an extension with IP46_SUPPORTED. For interoperability, the latest may be preferred. * 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. In that case maybe the IP6 should be provided with the notification ,in case the host really wants a IP4 address. * While 3gpp use case is sufficient, I am wondering if we have use cases outside 3gpp where such extension is needed ?
Of course these could be discussed after adoption. Yours, Daniel On Wed, Oct 17, 2018 at 9:27 AM Tommy Pauly <[email protected]> wrote: > Agreed with Valery that this is a fine starting point to define the > problem, but we will need to iterate on the details. > > I do support adoption. > > Thanks, > Tommy > > > On Oct 16, 2018, at 11:59 PM, Valery Smyslov <[email protected]> > wrote: > > > > Hi, > > > > after reading the draft's introduction, I think the problem described > > is real. So I support adoption of this draft. > > > > That said, it seems that the current draft solves the problem in > > suboptimal way (too many new notifications defined), but that > > can be definitely discussed in the WG. And yes, I'm ready to > > review the draft. > > > > Regards, > > Valery. > > > >> Our new charter has been approved and that includes item: > >> > >> RFC7296 defines a generic notification code that is related to a > >> failure to handle an internal address failure. That code does not > >> explicitly allow an initiator to determine why a given address > >> family is not assigned, nor whether it should try using another > >> address family. The Working Group will specify a set of more > >> specific notification codes that will provide sufficient > >> information to the IKEv2 initiator about the encountered failure. > >> A possible starting pointing is > >> draft-boucadair-ipsecme-ipv6-ipv4-codes. > >> > >> So this email will start one week long WG adoptation call for that > >> document [1] for WG adoptation. > >> > >> Send your comments to this list before the 2018-10-21. > >> > >> [1] > https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/ > >> -- > >> [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 >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
