Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

<> Wed, 11 February 2015 10:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E6D481A87BF for <>; Wed, 11 Feb 2015 02:22:25 -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 xQxo9iplorkx for <>; Wed, 11 Feb 2015 02:22:23 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4AAF91A1B8C for <>; Wed, 11 Feb 2015 02:22:23 -0800 (PST)
Received: from (unknown [xx.xx.xx.198]) by (ESMTP service) with ESMTP id B376E374212; Wed, 11 Feb 2015 11:22:21 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 8CF99180089; Wed, 11 Feb 2015 11:22:21 +0100 (CET)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([]) with mapi id 14.03.0224.002; Wed, 11 Feb 2015 11:22:21 +0100
From: <>
To: Lorenzo Colitti <>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
Thread-Index: AQHQRd9A94KoZb5URc+rHGKXMO3E0JzrOZNQ
Date: Wed, 11 Feb 2015 10:22:20 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933004908FF9@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <> <> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B933004908DF9@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933004908E6C@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933004908F65@OPEXCLILM23.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933004908FF9OPEXCLILM23corp_"
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2014.12.16.134821
Archived-At: <>
Cc: "" <>, V6 Ops List <>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
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: Wed, 11 Feb 2015 10:22:26 -0000


I really trust and defer to the chairs to decide whether the document is ready to be sent to the IESG, to be withdrawn, to be sent to ISE, or whatever action they judge appropriate to reflect the wg position.

My concern as an editor of the document is to understand why the document is harmful to IPv6 deployment, whether it contains technical flaws, understand what is meant by “harmfully abroad”, which aspects can be removed/tweaked so that it cannot be seen anymore “harmfully abroad”, etc. I’m in that stand, not somewhere else.

I would like to remind that the IETF is always asking to associate operators. This draft tries to have common voice from a group of operators who think there is a void in existing RFCs and a document is still needed. Note, the items listed in the document are all RFCs or specifications from 3GPP or GSMA.


De : Lorenzo Colitti []
Envoyé : mercredi 11 février 2015 10:44
Cc : Heatley, Nick; Fred Baker (fred);; V6 Ops List
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

On Wed, Feb 11, 2015 at 12:51 AM, <<>> wrote:

The document was adopted by the WG and passed both the WG and IETF LCs with that scope. I naively assumed that this point is not anymore an issue given that the draft passed major milestones (several WGLCs, IETF LC) and the IETF consensus declared for it means this is not an issue to advance the document.
I think that assumption is incorrect, given Fred's explicit statement on this thread, "Before I bother the IESG with it a third time, I’d really like to hear a clear consensus, not a rough one."