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

Lorenzo Colitti <lorenzo@google.com> Thu, 12 February 2015 22:23 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8132A1A0451 for <v6ops@ietfa.amsl.com>; Thu, 12 Feb 2015 14:23:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSo3Yc0tcxXz for <v6ops@ietfa.amsl.com>; Thu, 12 Feb 2015 14:23:57 -0800 (PST)
Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBAAA1A044D for <v6ops@ietf.org>; Thu, 12 Feb 2015 14:23:56 -0800 (PST)
Received: by iecrl12 with SMTP id rl12so13112766iec.4 for <v6ops@ietf.org>; Thu, 12 Feb 2015 14:23:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HetCTz/BVP9chFyep0bvmtXhKuFtYN2EalohWFhsAd8=; b=fVxdg4Lh4051iSjOwD+UrOez8XKOYqR19iRbTHXSu9XHnm9NINj9nUuzygD17TBYUm ihpJKrXXxk3p9NWTo61T3ki/Dujt6dMPrHKNa1AwnXUsZs6mwwenSV2X+4tMfcl3LqrI 8SjtrXBD8qljLjSgA4+edTqcxXpwpwIJPv3WeBMBLefsmmD0I3emPmZPNQZu82NhW4Kn SVJXsTig8vdAYochbvfubkGpplZ0ScKQaDRIgSAvfrLQwOGbGvw91l+uHgt6Y1VQ3LMd 1dX/VIauKxX+tQi0FVPYI1CdLi1MCpjRuFIvbbJCo+m7DjD0tS9kEqnIw4j78h+VJLay FuLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HetCTz/BVP9chFyep0bvmtXhKuFtYN2EalohWFhsAd8=; b=S3BJUexEUYGd9UocOC3Ps02j++N966t7/rvIiFlnelLh/I9+x1vxsAnN8XR+8QP//2 2rsp9BiGQszg0oNEGXBPlmDb8QKcGcmpWtt8OL/v7m5TWJPt2vZ2UvdmL1x8Br+h2CEJ 8bUyi0pNGjM5AZShTARXz8Qss/O8YXAIYScKz5Cvdrhkgkwv/77lzHVWr10p0EA5ZnN9 MsXuZMkyYChzceNOoX6Gbxb3WLWewPgvv6Nnf8e9OPahulRjFHOX4Kyp4MYbyfAcCbs7 53lARfGnmNTIVD/cb9UzcnLYiRdBgWAtLeI7Ut+P8VqIzJ6kVfB88V4xpWCh27LqO47P uJTw==
X-Gm-Message-State: ALoCoQknQnZ7FCm8NVVLoYguk6tXwbQKuippKGCJ+sNmovGXJ1ManHT9mod6+BMVQvo/4GE751VN
X-Received: by 10.107.134.103 with SMTP id i100mr7615018iod.90.1423779836274; Thu, 12 Feb 2015 14:23:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.33.104 with HTTP; Thu, 12 Feb 2015 14:23:36 -0800 (PST)
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 12 Feb 2015 14:23:36 -0800
Message-ID: <CAKD1Yr2yDnwPDHgsq3Wi3UOzKY7KrqSpBMbBttJ5qAAu6ijOAw@mail.gmail.com>
To: "<mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com>
Content-Type: multipart/alternative; boundary=001a113ece62614a77050eeb93db
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/lSy84YpHIoaLH_9UnbSfuX68gFs>
Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" <draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org>, V6 Ops List <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Feb 2015 22:23:59 -0000

On Wed, Feb 11, 2015 at 4:09 AM, <mohamed.boucadair@orange.com> 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).