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 <smyslov.i...@gmail.com> 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/ >> -- >> kivi...@iki.fi >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
