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

<mohamed.boucadair@orange.com> Fri, 20 February 2015 06:54 UTC

Return-Path: <mohamed.boucadair@orange.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 C38D91A03AB for <v6ops@ietfa.amsl.com>; Thu, 19 Feb 2015 22:54:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 mqJ8WP_OtV20 for <v6ops@ietfa.amsl.com>; Thu, 19 Feb 2015 22:54:41 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98D11A6ED9 for <v6ops@ietf.org>; Thu, 19 Feb 2015 22:54:40 -0800 (PST)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id D37741B851A; Fri, 20 Feb 2015 07:54:38 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id A1ADA158113; Fri, 20 Feb 2015 07:54:38 +0100 (CET)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Fri, 20 Feb 2015 07:54:36 +0100
From: mohamed.boucadair@orange.com
To: Lorenzo Colitti <lorenzo@google.com>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?
Thread-Index: AQHQTEy9ixBJZ1L350WogIuKXDMPO5z5FkZQ
Date: Fri, 20 Feb 2015 06:54:35 +0000
Message-ID: <dd61f165-9328-4454-aa38-ff9d6e9cf162@OPEXCLILH04.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <CAKD1Yr2yDnwPDHgsq3Wi3UOzKY7KrqSpBMbBttJ5qAAu6ijOAw@mail.gmail.com> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <CAKD1Yr0j23E-UMdL2Ujv5nrpbbUa9rgPE_6AhbHLn0JeOZ9Edg@mail.gmail.com> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <CAKD1Yr2PX81czTwUZzaMtgPc9vhvP=oL++UZByGzxmkq_B=DMA@mail.gmail.com> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <CAKD1Yr0Zkic6-ydV-u==xjDGdY9GYWb8KwciBPnfk8zO=6FFqQ@mail.gmail.com> <CAKD1Yr0qS-Vg-XB7mNWwephkkL5rCG+NJO7uDJg_4W3LT+Q9Ew@mail.gmail.com> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <CAKD1Yr00Ri8hQMsJcSqMAw+g_T-mU8GxG1G8rTHgo=McaKdW8Q@mail.gmail.com> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> <CAKD1Yr2+BMSifTS3x0WD5LqKYe-Yse8CGf4Egaijp=8DVSf5UA@mail.gmail.com> <fdc7ab8c-4f63-43eb-a77b-4764f24d9486@OPEXCLILH01.corporate.adroot.infra.ftgroup> <D10B3F46.1A731%dave.michaud@rci.rogers.com> <CAKD1Yr0zig7DY6npfe6JiKjmhojxTohV2==+C26zLVAU5CMo3w@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93300490E580@OPEXCLILM23.corporate.adroot.infra.ftgroup> <CAKD1Yr1ZEfocFOL8dRhqOL388R0x7-3iQGiZ_hARoZn94qdRtw@mail.gmail.com> <9ee5ae8c-9566-4e50-afae-38e96e1247fc@OPEXCLILH01.corporate.adroot.infra.ftgroup> <CAKD1Yr3PUVuhUGqQd-tX_TnaY34CDWWDBke495OuagYDFKqNUw@mail.gmail.com> <e81d9ae2-6b05-4880-b489-ffb116e8e11c@OPEXCLILH03.corporate.adroot.infra.ftgroup> <CAKD1Yr27uAsXnv8Aa6+Gm1k+Q9nmCqZpxjEHmDMuchQcODd7FA@mail.gmail.com>
In-Reply-To: <CAKD1Yr27uAsXnv8Aa6+Gm1k+Q9nmCqZpxjEHmDMuchQcODd7FA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: multipart/alternative; boundary="_000_dd61f16593284454aa38ff9d6e9cf162OPEXCLILH04corporateadr_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/DsvkmoRj221LQxp6cLC9M_RUJmk>
Cc: "IPv6 Ops WG (v6ops@ietf.org)" <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: Fri, 20 Feb 2015 06:54:44 -0000

Lorenzo,

Items included in the I-D are specified in existing RFCs, 3GGP or GSMA specifications. We are not “inventing” new features!

Actually, I don’t see the point of this discussion that started with a concern about "harmfully broad" but ends now with: this is not within the charter of v6ops!

If the point is to raise an objection then you can find more serious ones but not this one. It is incongruent to discuss this point about the charter at this stage: especially given the document was already accepted by the WG, passed the WGLC twice, and an IETF consensus was declared for it once.

As a reminder, below what we have implemented to address your concerns:

·         We integrated the text change you asked for when the WGLC was immediately initiated,

·         We clarified your concern about non prioritizing the recommendations,

·         We clarified the point that the compliancy with the document does not mean all items must be supported,

·         We reduced the scope of the document and listed items from 34 to 18 (5 of these items are for device with LAN capabilities, while 5 are advanced features).

I still have energy to address any serious concern you would have. If you can provide text this would even be better.

This document is also yours. As editors, we are recording what we hear from the WG.

Thank you.

Cheers,
Med

De : Lorenzo Colitti [mailto:lorenzo@google.com]
Envoyé : jeudi 19 février 2015 15:03
À : BOUCADAIR Mohamed IMT/OLN
Cc : Dave Michaud; BINET David IMT/OLN; IPv6 Ops WG (v6ops@ietf.org)
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

On Thu, Feb 19, 2015 at 10:46 PM, <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:

Not really. If you go and read those documents, you'll see none of them is on host requirements.

[Med] With all due respect, this is not true. RFC7066 is an example of host requirements.

The main purpose of RFC 7066 is not to place requirements of its own, but to clarify the requirements that are posed on hosts by the 3GPP standards.

 And in any case, the discussion was whether this document is "directly in line with the v6ops charter", as Dave said. Just because the WG happens to have published a few documents that talk about hosts doesn't mean that host requirements are directly in line with the charter.

[Med] What I know is that this document was adopted by the WG and passed the IETF LC once. The question about the charter was never raised.

I don't see what WG adoption and IETF LC have got do do with this discussion. Dave said the document is "directly in line with the v6ops charter", and I disagreed.

That document is a good example of what *is* in charter of the WG: an in-depth, detailed discussion of the operational issues. 8 lines of text saying "devices must support different PDP types for home and roaming" is not.

[Med] There is no recommendation in the roaming analysis draft. The profile document includes a clear recommendation on the current plan of most operators to handle the roaming issue.

But it's not the role of the IETF or of this working group to make statements about operator plans.
[Med] Who is asking for this?! This is your assumption, at most.

You're the one who wrote the words "the profile document includes a clear recommendation on the current plan of most operators". All I'm saying is that that's not the IETF's role.