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

"STARK, BARBARA H" <> Wed, 18 February 2015 16:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3626F1A89F9 for <>; Wed, 18 Feb 2015 08:20:44 -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 xFn7hB1-vu0X for <>; Wed, 18 Feb 2015 08:20: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 B09BB1A89FD for <>; Wed, 18 Feb 2015 08:20:32 -0800 (PST)
Received: from unknown [] (EHLO by with ESMTP id (envelope-from <>); Wed, 18 Feb 2015 16:20:32 +0000 (UTC)
X-MXL-Hash: 54e4bbd030e4c5d1-ac404a69881722f7cdbb78f880a6edefb0646901
Received: from unknown [] (EHLO by over TLS secured channel with ESMTP id (envelope-from <>); Wed, 18 Feb 2015 16:20:26 +0000 (UTC)
X-MXL-Hash: 54e4bbca57dd902a-51946cbbc4ce511b61d7cff3876b7ff6d762a374
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id t1IGKNcL006877; Wed, 18 Feb 2015 11:20:24 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t1IGKJGW006791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Feb 2015 11:20:20 -0500
Received: from ( []) by (RSA Interceptor); Wed, 18 Feb 2015 16:20:08 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 18 Feb 2015 11:20:07 -0500
To: "Heatley, Nick" <>, Lorenzo Colitti <>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?
Date: Wed, 18 Feb 2015 16:20:07 +0000
Message-ID: <>
References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <> <> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <> <> <> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <> <> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <> <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK>
In-Reply-To: <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK>
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=V6DKJ5bi c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=hoBwcu8XsvUA:10 a=BLceEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP]
X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=0HtSIViG9nkA:10 a=Rk_B-SlLw]
X-AnalysisOut: [kFu32K_rJUA: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- "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: Wed, 18 Feb 2015 16:20:44 -0000

> So all this document is doing is setting a collective roadmap, rather than expect vendors to do their own thing. Given we agree on the above, this is not harmful.

It’s not clear to me who this “collective” is. It seems like here the "collective" is the set of authors, but some people fear the outside world might view "collective" as "IETF". That seems to be a major sticking point, and, I think, the perceived potential "harm". It's very clear to me that "collective" is not "IETF" (and informational RFCs should never be seen as "collective" = "IETF", though some on the outside do have difficulty with this concept); nor is "collective" all wireless operators. It's just the authors.

I remember back when DSL was in its infancy, and telcos were struggling to deploy due to the lack of DSLAMs and DSL modems. Several got together, formed a single-purpose "joint procurement group", defined common requirements, and all issued the same RFP.  This was done external to all SDOs or other industry groups. Companies who were not part of this joint procurement group benefited as well, because then they could say "I'll have what they're having." It's very common for the companies who deploy later to use the approach of deploying what the "market leaders" are deploying. This way they don't need to have people who read/understand RFCs and such. They just trust that the "market leaders" have such people and know what they're doing. An added benefit of waiting for "market leader" deployment is that "unrealistic" RFP requirements have been weeded out by that time. As someone who has helped write many RFPs I can say with certainty that there were "must" items in all those RFPs that never made it into the deployed products. Once a timeline or price tag is associated with a "must", it can lose its "must"-ness.