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

<> Thu, 19 February 2015 12:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F29F21A8FD7 for <>; Thu, 19 Feb 2015 04:32:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.298
X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hg91a_0STS-W for <>; Thu, 19 Feb 2015 04:32:07 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C9FDF1A8FD3 for <>; Thu, 19 Feb 2015 04:32:06 -0800 (PST)
Received: from (unknown [xx.xx.xx.3]) by (ESMTP service) with ESMTP id 3F6D418C105; Thu, 19 Feb 2015 13:32:01 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 1AEB14C072; Thu, 19 Feb 2015 13:32:01 +0100 (CET)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([]) with mapi id 14.03.0224.002; Thu, 19 Feb 2015 13:32:01 +0100
From: <>
To: Lorenzo Colitti <>, "Heatley, Nick" <>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?
Thread-Index: AQHQTC2TixBJZ1L350WogIuKXDMPO5z34qow
Date: Thu, 19 Feb 2015 12:32:01 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300490E4E7@OPEXCLILM23.corporate.adroot.infra.ftgroup>
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> <787AE7BB302AE849A7480A190F8B93300490D690@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300490DAE5@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303E097FB@UK30S005EXS06.EEAD.EEINT.CO.UK> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300490E4E7OPEXCLILM23corp_"
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2015.2.19.110025
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: Thu, 19 Feb 2015 12:32:09 -0000


Thank you for the kind suggestion but I’m all optimist the I-D can be published in the IETF stream. If the IETF consensus was declared once, I’d hope this will happen for this version having a restricted scope (

It is obvious there is a void filled by this draft. It is built on existing RFCs already published in this area. This document is not original in its ambition nor it is different in its structure.

Technical issues can always be fixed (or at worse recorded), disagreements can be acknowledged, compromises can be found, the scope can be adjusted, etc.


De : Lorenzo Colitti []
Envoyé : jeudi 19 février 2015 11:20
À : Heatley, Nick
Cc : BOUCADAIR Mohamed IMT/OLN; Ca By; IPv6 Ops WG (
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

On Thu, Feb 19, 2015 at 6:14 PM, Heatley, Nick <<>> wrote:
If another body could be accountable for the document, that it represents the views of a suitable collective (mobile operators), but the technical content was filtered via IETF, that would be ideal, no?
I have no idea how to engineer such an outcome, but if it could be done then this work should not be wasted – could be a “GSMA sponsored RFC”?

You could make it an independent submission, and say that it represents the recommendations of the authors (see RFC 4846 for a description of the process, or RFC 6732 for an example of such an independent submission RFC).

If what you're after is IETF expertise, then I think the document has had plenty of exposure to that already, given it's been in the WG for over a year and a half.