Bonjour Eric, Thank you for the comments.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Éric Vyncke via Datatracker [mailto:nore...@ietf.org] > Envoyé : lundi 14 décembre 2020 09:17 > À : The IESG <i...@ietf.org> > Cc : draft-ietf-ipsecme-ipv6-ipv4-co...@ietf.org; ipsecme- > cha...@ietf.org; ipsec@ietf.org; David Waltermire > <david.walterm...@nist.gov>; Yoav Nir <ynir.i...@gmail.com>; > ynir.i...@gmail.com > Objet : Éric Vyncke's No Objection on draft-ietf-ipsecme-ipv6-ipv4- > codes-05: (with COMMENT) > > Éric Vyncke has entered the following ballot position for > draft-ietf-ipsecme-ipv6-ipv4-codes-05: No Objection > > When responding, please keep the subject line intact and reply to > all email addresses included in the To and CC lines. (Feel free to > cut this introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss- > criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes/ > > > > -------------------------------------------------------------------- > -- > COMMENT: > -------------------------------------------------------------------- > -- > > Bonjour Med, > > Thank you for the work put into this document. The shepherd write-up > is really terse but reflects that it was a rough consensus. > > Please find below some non-blocking COMMENT points (but replies > would be appreciated), and some nits. > > I hope that this helps to improve the document, > > Regards, > > -éric > > == COMMENTS == > > -- Abstract -- > The one-line abstract does not really explain/summarize what this > document is about. E.g., nothing is mentioned about 3GPP origin. > Expanding the abstract with something like "by allowing the > responder to signal to the initiator which address families are > supported". [Med] Fixed with s/supported/allowed. Thanks. > > -- Section 1 -- > The sentence "When the UE attaches the network using a WLAN access > by means of > IKEv2 capabilities, there are no equivalent notification codes ..." > looks cryptic to me. What is the link with WLAN access and IKEv2 ? > [Med] WLAN is an example of what 3GPP calls "non-trusted access network". In such case, an IKEv2/IPsec is used to connect to the "3GPP network". We wanted to avoid overloading the text with 3GPP terms + avoid distracting the reader about trusted/non-trusted accesses. See the updated text at: https://tinyurl.com/ike-v4v6-codes. Better? > -- Section 5 -- > "If a dual-stack initiator requests only an IPv6 prefix (or an > IPv4 > address) but only receives IP4_ALLOWED (or IP6_ALLOWED) > notification > status type from the responder, the initiator MUST send a request > for > IPv4 address(es) (or IPv6 prefix(es))." > > Is it really a "MUST" and not a "SHOULD" or even "MAY" ? A > constrained UE may have IPv6-only applications and, even if OS is > dual-stack, not bothers to have a useless IPv4 address. > [Med] Such constrained UE should be tweaked to behave as an "IPv6-only initiator". That is local to the UE. > The paragraph after this one mimics the 3GPP PDP behavior, but, does > it make sense for IKEv2 ? [Med] We want to have a functional parity for an UE independently of the access it uses to graft to a 3GPP network. > > == NITS == > > In several places, the word "responder" is misspelled. [Med] Fixed the one reported by Murray. Will double check. > > In some places, a ':' is followed by a capitalized word which looks > weird to my French-reading eyes... [Med] That's OK for the RFC Editor. You may check https://tools.ietf.org/html/rfc8801 :-) _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
