Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

"STARK, BARBARA H" <> Fri, 13 February 2015 14:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 605881A7D84 for <>; Fri, 13 Feb 2015 06:05:46 -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 bM6MIWwFpFMu for <>; Fri, 13 Feb 2015 06:05:42 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 395581A7D82 for <>; Fri, 13 Feb 2015 06:05:41 -0800 (PST)
Received: from unknown [] (EHLO by with ESMTP id (envelope-from <>); Fri, 13 Feb 2015 14:05:41 +0000 (UTC)
X-MXL-Hash: 54de04b52a0e416e-8887eeca4d6afb2a97fdc8a2e40c787cb1dd52d4
Received: from unknown [] (EHLO by over TLS secured channel with ESMTP id (envelope-from <>); Fri, 13 Feb 2015 14:05:40 +0000 (UTC)
X-MXL-Hash: 54de04b448fe7dcf-20d36975c1d86c5a9a412953bf00e85c0e7ecb57
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id t1DE5cmv021019; Fri, 13 Feb 2015 09:05:39 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t1DE5Wll020952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Feb 2015 09:05:33 -0500
Received: from ( []) by (RSA Interceptor); Fri, 13 Feb 2015 14:05:23 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Fri, 13 Feb 2015 09:05:23 -0500
To: Alexandru Petrescu <>, "" <>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?
Date: Fri, 13 Feb 2015 14:05:23 +0000
Message-ID: <>
References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=ApVZKpBP c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=vKzWRVGcsRAA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP]
X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=0HtSIViG9nkA:10 a=SgCuRERWA]
X-AnalysisOut: [AAA:8 a=wP04zbwDicQiNb1o5OoA:9 a=CjuIK1q_8ugA:10]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
Archived-At: <>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?
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, 13 Feb 2015 14:05:46 -0000

> When I go through procurements often the vendors ask the RFC list that
> need to be there.  This criterion - the implemented RFC list - primes over all
> others such as software management, dimensions, price tags, electrical,
> temperature and noise features.  If it were not for these little RFCs there
> would be no reasonable procurement.
> That said, I also agree with you when you imply that the list of features in this
> draft may be too long, or too hard see coherence.
> If so, then maybe we can try to reduce it a bit?
> Finally, 'profile' is probably not the right title.  It should qualify both the end-
> user device and the network device.

Inside the company I work for, I try to encourage "thoughtful" use of "device profile" RFCs such as this draft may become. That is, read through the entire RFC, and make sure you want everything that's mandated. If you don't, pick and choose what makes sense for the product you are procuring. I would definitely not recommend to anyone (inside or outside my company) that they ask for compliance with this document without fully understanding the implications of what they are asking for. Basically, I see the items listed in the draft as a set of potential items to consider when putting together an RFP.

As it relates to IPv6 "device profile" documents, I would like to mention that CableLabs has been successful with its eRouter spec, BBF successful with its TR-124, and I'm hoping CEA has impact on the CE industry with its new CEA2048 publication (which they're offering for free through Feb 28 -- see There does seem to be demand for "device profile" documents. I do think the only reason RFC 7084 (which really is a "device profile" RFC) was done in IETF was because of the need to identify requirements for CE routers that could connect to a variety of access network architecture, and IETF was "neutral territory". I admit to finding it odd that IETF would be used to publish a device profile that is only for devices connecting to 3GPP access networks. But I'm not familiar with how 3GPP works, so maybe it wasn't possible to get 3GPP to be willing to create a profile for devices that attach to their access network.

BTW, I'm very concerned about the fact that someone affiliated with a provider of an OS found on many  3GPP devices has so many objections to this particular "device profile". Knowing that, I would very, very strongly recommend to people I work with that they be very, very careful about how they use this particular "device profile" (if at all). I would not suggest including it directly in any RFP.