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

"Heatley, Nick" <> Fri, 13 February 2015 15:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 71A0F1A8742 for <>; Fri, 13 Feb 2015 07:33:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j4R87ge8Lza7 for <>; Fri, 13 Feb 2015 07:33:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C6D041A8750 for <>; Fri, 13 Feb 2015 07:33:37 -0800 (PST)
Received: from [] by id 96/A9-03511-0591ED45; Fri, 13 Feb 2015 15:33:36 +0000
X-Originating-IP: []
X-StarScan-Version: 6.13.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26905 invoked from network); 13 Feb 2015 15:29:16 -0000
Received: from unknown (HELO ( by with DHE-RSA-AES256-SHA encrypted SMTP; 13 Feb 2015 15:29:16 -0000
Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[]) by with MailMarshal (v7, 2, 3, 6978) (using TLS: SSLv23) id <B54de18450002>; Fri, 13 Feb 2015 15:29:09 +0000
Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id <B54de184b0001>; Fri, 13 Feb 2015 15:29:15 +0000
Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0195.001; Fri, 13 Feb 2015 15:29:15 +0000
From: "Heatley, Nick" <>
To: "STARK, BARBARA H" <>, "IPv6 Ops WG (" <>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?
Thread-Index: AdBF852OT93fqpMASLCB8yKRPPF6QABHu1kAAB3XhwAAAwysgAACEdnQ
Date: Fri, 13 Feb 2015 15:29:15 +0000
Message-ID: <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK>
References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, 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
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 15:33:43 -0000

I find your comments very well considered, thank you.

Barbara, ultimately the question remains, will your people be better off having read a document, with all the appropriate contextual warnings (i.e. it is not a standard), than if the paper did not exist? (Do you expect them to read all RFCs?)

To use an analogy  I am not the "specialist surgeon", but a GP* wondering what to vaccinate my patients with.
I don't wish to know, or understand, every new breakthrough in every disease.
I wish the specialists to agree what is ready for patients.
With approaching 10k of RFCs, and given I would hope to fully read 20 a year, I have little chance of keeping up.
My devices team, well, If I can get them to read one paper. (What else can I do, tell them to a RFC search on "mobile"?)
So I'd like the specialists to distill there wisdom into a useable form to take to the front line.
That is why I need a profile paper.
Lorenzo, I feel you are like the specialist surgeon berating the GPs for not knowing every RFC in its pure form.
We have a difficult job dealing with the front line here.
If terminal folks really don't need to know about some of these items, lets remove them.

Perhaps the IETF leads should think about a class of document for exactly this need. 
It is not a pure standards paper, and should not be judged as so.
It could have all the health warnings that Barbara et al would like to see.
Better to have it than not - that is my view.

I only see these becoming more prevalent, we are no longer in an industry where a handful of IP vendors roll out the latest RFCs into code.
Soon every electronic device will have an IP stack, IP features and more. IP Developers will soon be like GPs, not specialists! Help them out.
* I don't know if GP is an international term - General Practitioner means  local doctor who sees patients in the surgery!

-----Original Message-----
From: v6ops [] On Behalf Of STARK, BARBARA H
Sent: 13 February 2015 14:05
To: Alexandru Petrescu;
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

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

v6ops mailing list
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.  
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. 

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW.