Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

<> Mon, 02 February 2015 12:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 86E541A032D for <>; Mon, 2 Feb 2015 04:38:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QZ-9LSP_Qpcy for <>; Mon, 2 Feb 2015 04:38:06 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C9981A0277 for <>; Mon, 2 Feb 2015 04:38:05 -0800 (PST)
Received: from (unknown [xx.xx.xx.199]) by (ESMTP service) with ESMTP id A342A3B426F; Mon, 2 Feb 2015 13:38:01 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 83FEFC8080; Mon, 2 Feb 2015 13:38:01 +0100 (CET)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([]) with mapi id 14.03.0224.002; Mon, 2 Feb 2015 13:38:01 +0100
From: <>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
Date: Mon, 2 Feb 2015 12:38:01 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933004903953@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <> <> <> <787AE7BB302AE849A7480A190F8B933004902567@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933004902B03@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B9330049034C8@OPEXCLILM23.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330049034C8@OPEXCLILM23.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2015.2.2.110619
Archived-At: <>
Cc: IPv6 Ops WG <>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Feb 2015 12:38:08 -0000


Your proposed change has been integrated in the new version: 

Please let me know if this solves your concern. Thank you.


-----Message d'origine-----
De : v6ops [] De la part de
Envoyé : lundi 2 février 2015 07:33
À : STARK, BARBARA H; James Woodyatt
Cc : IPv6 Ops WG
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

Hi Barbara,

Please see inline.


-----Message d'origine-----
Envoyé : vendredi 30 janvier 2015 18:45
À : BOUCADAIR Mohamed IMT/OLN; James Woodyatt
Cc : IPv6 Ops WG
Objet : RE: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

> As per RFC7084, we didn't included it because it included some IPv4
> continuity service features that are not valid for the mobile context. The
> document already mentions the following:
>                 "Note, even if RFC7084 obsoletes [RFC6204], this profile
>                 does not require RFC7084 because IPv4 service continuity
>                 techniques used in mobile networks are not the same as
>                 in fixed networks."

Requiring compliance to an obsoleted RFC (6204) Especially since RFC 7084 fixed several items in 6204 that needed fixing. I, personally, would not recommend anything be compliant with RFC 6204.

Also note that DS-Lite and 6rd are "SHOULD" requirements in RFC 7084. It is totally possible for a device to be 100% compliant with RFC 7084 and not do either DS-Lite or 6rd. 

[Med] I fully agree ... but, unfortunately,  this interpretation is not shared. It seems that some think that ALL items mentioned in a document (whatever the language used for individual items) must be supported which is not true. 

Surely mobile device manufacturers are intelligent enough to recognize that there is a very good reason for them not to do DS-Lite or 6rd (because these aren't used in 3GPP networks)? It would also be possible to explicitly note that these technologies are not used or needed for connecting to 3GPP networks.

It's my understanding that when an RFC is obsoleted by another RFC, readers are supposed to consider the new RFC as a replacement for the obsoleted RFC, every time they see a reference to the obsoleted RFC. So a brand new reference to an obsoleted RFC, for me, is rather bizarre. It's boggling my mind.

[Med] I hear you. I will remove the obsolete reference + add a sentence to exclude IPv4 service continuity features mentioned in RFC7084. 

 I'm not convinced that this reference to an obsoleted RFC will be understood in the manner you intend.

[Med] I will follow your suggestion. 

v6ops mailing list