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

Alexandru Petrescu <> Fri, 13 February 2015 12:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7D01C1A1EF5 for <>; Fri, 13 Feb 2015 04:38:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.983
X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G5OOFcI-lpSR for <>; Fri, 13 Feb 2015 04:38:29 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 38A861A1BA7 for <>; Fri, 13 Feb 2015 04:38:29 -0800 (PST)
Received: from ( []) by (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1DCcRm6023156 for <>; Fri, 13 Feb 2015 13:38:27 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id 1883B204227 for <>; Fri, 13 Feb 2015 13:39:23 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 0F707203CE8 for <>; Fri, 13 Feb 2015 13:39:23 +0100 (CET)
Received: from [] ( []) by (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1DCc4cf004826 for <>; Fri, 13 Feb 2015 13:38:27 +0100
Message-ID: <>
Date: Fri, 13 Feb 2015 13:38:04 +0100
From: Alexandru Petrescu <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
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 12:38:32 -0000


I wanted to express my oppinion.  I have read your email at the time, 
and now.

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.


Le 12/02/2015 23:23, Lorenzo Colitti a écrit :
> On Wed, Feb 11, 2015 at 4:09 AM, <
> <>> wrote:
>     Can you explicit what do you meant by “harmfully broad”?
>     (note, the pointer you provided is not valid because several items
>     have been removed from the draft since then.)
> Ok, then. Since you ask, let me copy and paste the text from the
> pointer, then, and we can discuss why it is no longer valid.
> =====
> I object to this document on the grounds that it is little more than a
> list of (34!) features with little technical justification. I see this
> as a problem because:
> 1. It is out of the IETF's mandate. It is not the IETF's job to specify
> which features or protocols should or should not be implemented in
> hosts. Even the hosts requirements RFCs are careful and sparing in their
> language. The IETF is certainly not in the business of rubberstamping
> feature wishlists without good technical reasons. I would challenge the
> authors to find a precedent RFC containing such broad requirements.
> 2. It is over-broad. The vast majority of the features are in no way
> necessary to build a mobile device that works well over IPv6. Today, the
> overwhelming majority of mobile device traffic comes from devices that
> implement only a handful of these requirements. More specifically,
> requirements #3, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19,
> #20, #21, #22, #23, #24, #25, #26, #27 (a whole RFC!), #28, #29, #31,
> #32 (which cover all applications running on the device - yes, all of
> them), and #34, are not necessary to connect to IPv6 mobile networks.
> 3. It is so daunting as to act as a deterrent to IPv6 deployment. I
> would challenge the authors to find a single product today that
> implements all, or even a substantial majority, of these requirements.
> It seems to me that the sheer length of the list, and the fact that is
> not prioritized, create a real risk that implementors will simply write
> it off as wishful thinking or even shy away in terror.
> 4. The document has few technical contributions of its own. Most of the
> requirements are simply listed one after another.
> I'm all for IPv6 deployment in mobile networks, but making a list of
> what seems like all the features that the IETF has ever developed, and
> then saying that they all need to be implemented, is not the way to get
> there. The way to do it is to document use cases and working scenarios
> gleaned from operational experience.
> ====
> The way I see it, the recent changes made to the document do nothing to
> address the substance of those points.
> It's true that the document no longer lists 34 features, only 23, but it
> looks like the reduction has been mostly effected by removing features
> that were already mandatory IETF or 3GPP requirements (e.g., REQ#1,
> "must support IPv6 addressing architecture and ICMPv6 node
> requirements", REQ#6, "must support IPv6 neighbour discovery") and
> coalescing multiple features into one, (e.g., REQ_2 and REQ_3 were
> merged into C_REC#2).
> _______________________________________________
> v6ops mailing list