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

joel jaeggli <joelja@bogus.com> Tue, 10 September 2013 16:52 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C23021F9FE5; Tue, 10 Sep 2013 09:52:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.455
X-Spam-Level:
X-Spam-Status: No, score=-101.455 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 91f5RCrlnKgB; Tue, 10 Sep 2013 09:52:37 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 20AD321F9BAD; Tue, 10 Sep 2013 09:52:34 -0700 (PDT)
Received: from mb-aye.corp.zynga.com (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r8AGqURU063106 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 10 Sep 2013 16:52:30 GMT (envelope-from joelja@bogus.com)
Message-ID: <522F4E48.9020206@bogus.com>
Date: Tue, 10 Sep 2013 09:52:24 -0700
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Owen DeLong <owen@delong.com>, mohamed.boucadair@orange.com
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
References: <20130819135219.8236.40060.idtracker@ietfa.amsl.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> <CAKD1Yr0_yOaDjrH-5K696YaziZZR+EMxdRCf=JZBW5LZgWS45Q@mail.gmail.com> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <CAKD1Yr3cgJ-xumsMK3eL3zySGsPqXU9uw4L857bJ0VEGcA5mBQ@mail.gmail.com> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <179F53B5-6217-49A0-B5FE-A88011533860@delong.com>
In-Reply-To: <179F53B5-6217-49A0-B5FE-A88011533860@delong.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 10 Sep 2013 16:52:31 +0000 (UTC)
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>, IETF Discussion <ietf@ietf.org>, Lorenzo Colitti <lorenzo@google.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2013 16:52:44 -0000

On 9/9/13 1:06 PM, Owen DeLong wrote:
> I have to agree with Lorenzo here again.
> 
> This document seems to me to be:
> 
> 1.Out of scope for the IETF.

AD here... let's put this one to bed. there are existance proof(s) of
previous work in this area and others that covers similar ground.

I don't believe that this is out of scope for the WG or the IETF,
Neither did the previous AD.

So... Focus on the contents.

> 2.So watered down in its language as to use many words to say nearly
> nothing.
> 3.Claims to be informational, but with so many caveats about the nature
> of that
> information that it's hard to imagine what meaningful information an
> independent
> reader could glean from the document.
> 
> Finally, given the spirited debate that has extended into this last call
> (which I honestly wonder
> how this ever saw last call over the sustained objections) definitely
> does not appear to have
> even rough consensus, nor does it appear to have running code.
> 
> Why is there such a push to do this?
> 
> Owen
> 
> On Sep 9, 2013, at 05:16 , <mohamed.boucadair@orange.com
> <mailto:mohamed.boucadair@orange.com>> wrote:
> 
>> Re-,
>>  
>> Please see inline.
>>  
>> Cheers,
>> Med
>>  
>> *De :* Lorenzo Colitti [mailto:lorenzo@google.com <http://google.com/>] 
>> *Envoyé :* lundi 9 septembre 2013 13:24
>> *À :* BOUCADAIR Mohamed IMT/OLN
>> *Cc :* Dave Cridland; v6ops@ietf.org <mailto:v6ops@ietf.org> WG; BINET
>> David IMT/OLN; IETF Discussion
>> *Objet :* 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
>>  
>> On Mon, Sep 9, 2013 at 8:06 PM, <mohamed.boucadair@orange.com
>> <mailto:mohamed.boucadair@orange.com>> wrote:
>>
>>     The document explicitly says “This document is not a standard.”
>>     since version -00.
>>
>>      
>>
>>     What additional statement you would like to see added?
>>
>>  
>> I think the high-order points are:
>>  
>> 1. The text "This document defines an IPv6 profile for 3GPP mobile
>> devices. It lists the set of features a 3GPP mobile device is to be
>> compliant with to connect to an IPv6-only or dual-stack wireless
>> network" should be replaced with "This document defines an IPv6
>> profile for 3GPP mobile devices that a number of operators believe is
>> necessary to deploy IPv6 on an IPv6-only or dual-stack wireless
>> network (including 3GPP cellular network and IEEE 802.11 network)."
>>  
>> In place of "a number of operators believe is necessary to deploy" you
>> could have "intend to deploy" or "require". I'd guess that as long as
>> it's clear that the requirements don't come from the IETF but from a
>> number of operators (not all of them, or a majority of them), it
>> doesn't matter exactly what you say.
>> */[Med] I made this change:/*
>> */ /*
>> */OLD:/*
>> */ /*
>>    This document defines an IPv6 profile for 3GPP mobile devices.  It
>>    lists the set of features a 3GPP mobile device is to be compliant
>>    with to connect to an IPv6-only or dual-stack wireless network
>>    (including 3GPP cellular network and IEEE 802.11 network).
>> */ /*
>> */New:/*
>> */ /*
>>    This document defines an IPv6 profile that a number of operators
>>    require in order to connect 3GPP mobile devices to an IPv6-only or
>>    dual-stack wireless network (including 3GPP cellular network and IEEE
>>    802.11 network).
>> */
>>
>> /*
>> 2. In the normative language section, I'd like to see a statement
>> similar to what's in RFC 6092. Perhaps something like this?
>> */[Med] I used the same wording as in RFC6092. The change is as follows:/*
>> */ /*
>> */OLD:/*
>> */ /*
>>    This document is not a standard.  It uses the normative keywords only
>>    for precision.
>> */ /*
>> */NEW:/*
>> */ /*
>>       NOTE WELL: This document is not a standard, and conformance with
>>       it is not required in order to claim conformance with IETF
>>       standards for IPv6.  It uses the normative keywords defined in the
>>       previous section only for precision.
>> */ /*
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org <mailto:v6ops@ietf.org>
>> https://www.ietf.org/mailman/listinfo/v6ops
>