Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update

Hesham Soliman <hesham@elevatemobile.com> Fri, 21 September 2012 13:19 UTC

Return-Path: <hesham@elevatemobile.com>
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 C78F221F8589 for <v6ops@ietfa.amsl.com>; Fri, 21 Sep 2012 06:19:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.341
X-Spam-Level:
X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XLcpi+UUsh2 for <v6ops@ietfa.amsl.com>; Fri, 21 Sep 2012 06:19:49 -0700 (PDT)
Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id BEB6321F8629 for <v6ops@ietf.org>; Fri, 21 Sep 2012 06:19:47 -0700 (PDT)
Received: from [60.242.128.199] (helo=[192.168.0.6]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1TF38s-00054H-KZ; Fri, 21 Sep 2012 23:19:39 +1000
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Fri, 21 Sep 2012 23:19:30 +1000
From: Hesham Soliman <hesham@elevatemobile.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
Message-ID: <CC82A5C8.29146%hesham@elevatemobile.com>
Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update
In-Reply-To: <DB308AF0-0FA7-43F5-B511-8A21B84728C1@nominum.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-User: hesham@elevatemobile.com
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update
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: Fri, 21 Sep 2012 13:19:49 -0000

>
>On Sep 21, 2012, at 9:04 AM, Hesham Soliman <hesham@elevatemobile.com>
> wrote:
>> => But they're not the only way to support IPv6-only. There are many
>> different variations therefore SHOULD/MUST is way too strong. Please
>>check
>> the definitions of should and must.
>
>This response seems to be based on the assumption that many different
>device implementors will make many different choices, and that operators
>will therefore have to support every possible set of choices that may
>have been made when implementing each specific device.   This is the
>exact opposite of what a requirements document like this one is supposed
>to achieve.   The point of these requirements is to create a reasonable
>baseline set of expectations that operators can have about devices that
>will connect to their networks.

=> And has there been on consensus on that mechanism? Because if there is
consensus on one approach then lets remove a few more requirements. The
current draft seems to select two approaches from what I remember.


>If, as a device implementor, you don't want to have to implement the
>recommended functionality, that's fine, but then you can't claim to
>support the requirements in the document.
>
>Of course, a SHOULD requirement doesn't prevent you from claiming you
>support the document, unfortunately.   But at least is gives you a strong
>hint that the functionality is desirable, and its absence will mean that
>your device may not provide a good feature set on some operator networks.

=> Of course, but some IETF consensus needs to be established before
selecting a couple of mechanisms and saying that's it!
Speaking of which, I'm assuming the IPv6 WG is going to review this draft
as well. 

Hesham


>