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

<> Mon, 02 February 2015 06:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 215061A9241 for <>; Sun, 1 Feb 2015 22:32:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 1k3Rns-lbNAu for <>; Sun, 1 Feb 2015 22:32:50 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E579A1A1B94 for <>; Sun, 1 Feb 2015 22:32:49 -0800 (PST)
Received: from (unknown [xx.xx.xx.198]) by (ESMTP service) with ESMTP id A14761B8167; Mon, 2 Feb 2015 07:32:47 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 73947180067; Mon, 2 Feb 2015 07:32:47 +0100 (CET)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([]) with mapi id 14.03.0224.002; Mon, 2 Feb 2015 07:32:47 +0100
From: <>
To: "STARK, BARBARA H" <>, James Woodyatt <>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
Date: Mon, 2 Feb 2015 06:32:47 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330049034C8@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <> <> <> <787AE7BB302AE849A7480A190F8B933004902567@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933004902B03@OPEXCLILM23.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
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.22719
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 06:32:52 -0000

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.