Subject: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ipv6-ipv4-codes-05: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 14 Dec 2020 00:17:28 -0800

É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".

-- 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 ?

-- 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.

The paragraph after this one mimics the 3GPP PDP behavior, but, does it make
sense for IKEv2 ?

== NITS ==

In several places, the word "responder" is misspelled.

In some places, a ':' is followed by a capitalized word which looks weird to my
French-reading eyes...

---

From: <[email-masked]>
Date: Mon, 14 Dec 2020 09:00:05 +0000

Bonjour Eric, 

Thank you for the comments. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Éric Vyncke via Datatracker [mailto:[email-masked]]
> Envoyé : lundi 14 décembre 2020 09:17
> À : The IESG <[email-masked]>
> Cc : [email-masked]; ipsecme-
> [email-masked]; [email-masked]; David Waltermire
> <[email-masked]>; Yoav Nir <[email-masked]>;
> [email-masked]
> Objet : Éric Vyncke's No Objection on draft-ietf-ipsecme-ipv6-ipv4-
> codes-05: (with COMMENT)
> 
> 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.)
> 
> 
> 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.
> 
> 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. 

> 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? 

> 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. 

> 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.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 14 Dec 2020 09:39:10 +0000

Re-bonjour Med,

The suggested text sounds good to me. About the "MUST" in section 5, let's agree that we disagree on this one but this is NOT blocking.

There is another "repsonder" at the end of section 5 and I loved your reference to RFC 8801 (Monday morning smile!)

Regards

-éric

-----Original Message-----
From: iesg <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Monday, 14 December 2020 at 10:01
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Yoav Nir <[email-masked]>, David Waltermire <[email-masked]>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-ipsecme-ipv6-ipv4-codes-05: (with COMMENT)

    Bonjour Eric, 

    Please see inline. 

    Cheers,
    Med