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

"STARK, BARBARA H" <> Fri, 30 January 2015 17:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CFB8D1A212D for <>; Fri, 30 Jan 2015 09:45:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NSCx50TeJ4Ty for <>; Fri, 30 Jan 2015 09:45:28 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0B63B1A1BFE for <>; Fri, 30 Jan 2015 09:45:27 -0800 (PST)
Received: from unknown [] (EHLO by over TLS secured channel with ESMTP id (envelope-from <>); Fri, 30 Jan 2015 17:45:28 +0000 (UTC)
X-MXL-Hash: 54cbc33848a77371-8c69a1772d96b49135d3e584e3e8d7038c7e30e3
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id t0UHjLvK012000; Fri, 30 Jan 2015 12:45:25 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t0UHjAYB011043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Jan 2015 12:45:16 -0500
Received: from ( []) by (RSA Interceptor); Fri, 30 Jan 2015 17:44:54 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Fri, 30 Jan 2015 12:44:54 -0500
To: "" <>, "James Woodyatt" <>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
Date: Fri, 30 Jan 2015 17:44:54 +0000
Message-ID: <>
References: <> <> <> <787AE7BB302AE849A7480A190F8B933004902567@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933004902B03@OPEXCLILM23.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933004902B03@OPEXCLILM23.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=BpYqN/r5 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=tXTwz62Y0oYA:10 a=BLceEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP]
X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=YNv0rlydsVwA:10 a=SqHAGK2ZE]
X-AnalysisOut: [RW6ytXJafcA:9 a=QEXdDO2ut3YA:10]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
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: Fri, 30 Jan 2015 17:45:30 -0000

> 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. 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. I'm not convinced that this reference to an obsoleted RFC will be understood in the manner you intend.