Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 09 September 2013 10:58 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCAC21F8EB5 for <v6ops@ietfa.amsl.com>; Mon, 9 Sep 2013 03:58:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.912
X-Spam-Level:
X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3kqqEovhikQ for <v6ops@ietfa.amsl.com>; Mon, 9 Sep 2013 03:58:28 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 117F121E816A for <v6ops@ietf.org>; Mon, 9 Sep 2013 03:57:09 -0700 (PDT)
Received: from [10.255.133.212] ([194.251.119.201]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lx8vJ-1W2oOJ2vCz-016f8J for <v6ops@ietf.org>; Mon, 09 Sep 2013 12:57:07 +0200
Message-ID: <522DA977.4010807@gmx.net>
Date: Mon, 09 Sep 2013 13:56:55 +0300
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Dave Cridland <dave@cridland.net>
References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <CAKD1Yr1VpJne1h-Q5xbNMYRhpr_n0Wmn6UqfeG3vEg2MY6ms1g@mail.gmail.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <CAKD1Yr0pqeO9KdcKFWVqWP_5pmZ6fgQ5h4tQ=vOO57d-dg5+DA@mail.gmail.com> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <CAKD1Yr3SddZio-vHGHK=5smb94HP58cY05_TGgWQpkS3=Ay8_w@mail.gmail.com> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <CAKD1Yr0CUzSDv9H1eCUpMRUjBDS2OCkfsfE+S+3J8Z-_6=uVSg@mail.gmail.com> <CAKHUCzwYrjyobah-oPWD3vwUeUH5XZ7U=Fqof-f28tneS8jAvQ@mail.gmail.com>
In-Reply-To: <CAKHUCzwYrjyobah-oPWD3vwUeUH5XZ7U=Fqof-f28tneS8jAvQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:bWXasJD//YXQOjdEpgBZItRazULxwxJOZIdRMuu4MXuhq2WSyet i/oRplwgCO3ajAH5GllZ7SGItujpRb+NdzXfBg0NbfU1maccBbWC+p8KIodYkJQZhgOKtcH 4dcZ8g7Pk+c74K/ZPOE5tHvyXzyDdyYmwp50rr7ONUfIkzcVvLlw5RzHRxNGm62YpbSNe6L J4pByHho/LYQB9iWpyrZw==
X-Mailman-Approved-At: Mon, 09 Sep 2013 04:24:32 -0700
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>, IETF Discussion <ietf@ietf.org>, hannes.tschofenig@gmx.net
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 09 Sep 2013 10:58:41 -0000

Browsing through the document I am not sure how much weight is carries 
when an IETF working group defines what 3GPP networks should be doing, 
particularly when talking about protocols the 3GPP has not really 
expressed an opinion about.

 From the document it is unclear to me what requirements are directly 
taken from 3GPP specifications and what additional requirements the 
authors have added.

On 09.09.2013 13:19, Dave Cridland wrote:
>
>
>
> On Wed, Sep 4, 2013 at 10:25 AM, Lorenzo Colitti <lorenzo@google.com
> <mailto:lorenzo@google.com>> wrote:
>
>     I'm just saying it here so that everyone in the community can see
>     it. If it's an IETF document it has to have IETF consensus, and
>     since I feel that the arguments were not properly taken into account
>     in the WG (read: ignored), I think it's important that the community
>     see them before we publish this document.
>
>
> I'm not sure the consensus requirement you're suggesting actually
> exists. This is aiming at Informational, and as such:
>
>     An"Informational"  specification is published for the general
>     information of the Internet community, and does not represent an
>     Internet community consensus or recommendation.  The Informational
>
> [RFC 2026 §4.2.2]
>
>     But the IETF doesn't define profile documents. The IETF defines
>     technical standards on the basis of rough consensus and running
>     code. What you're saying is "since we don't have running code that
>     does what we want, we're trying to define a profile in the hope that
>     someone will write the code". That's not the way it works.
>
>
> No, the IETF has published profile documents in a number of cases. One
> could argue that RFC 1122 and RFC 1123 are both profile documents,
> actually, but there are other specific examples, like the Lemonade
> profile, for example.
>
> I suspect, however, that this document is actually a standard, or
> intended as one. There's discussion about conformance, about testing for
> conformance, and so on, which suggests that an operator (in particular)
> might treat any resultant RFC as a standard without regard for its IETF
> status. That's a concern, though in practise, if this is to be a
> document detailing "what operators want", I'd be happier that it's
> published through the IETF as Informational than not published at all -
> and in any case, no amount of pretence will alter the fact that people
> will treat any RFC as a standard if it suits them anyway.
>
> What may be more useful, though, would be to get more stakeholders
> involved in a commonly agreed profile, and supercede this.
>
> Dave.