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

Ted Lemon <Ted.Lemon@nominum.com> Fri, 21 September 2012 13:13 UTC

Return-Path: <Ted.Lemon@nominum.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 7F18721F8776 for <v6ops@ietfa.amsl.com>; Fri, 21 Sep 2012 06:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.427
X-Spam-Level:
X-Spam-Status: No, score=-106.427 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
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 nSn08bshcPba for <v6ops@ietfa.amsl.com>; Fri, 21 Sep 2012 06:13:58 -0700 (PDT)
Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id D546521F8770 for <v6ops@ietf.org>; Fri, 21 Sep 2012 06:13:57 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUFxoFfp/Yj4KuwRYLHl6bdqYwAkuJ/f5@postini.com; Fri, 21 Sep 2012 06:13:57 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 401501B82AD for <v6ops@ietf.org>; Fri, 21 Sep 2012 06:13:57 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 374E819005C; Fri, 21 Sep 2012 06:13:57 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 21 Sep 2012 06:13:57 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Hesham Soliman <hesham@elevatemobile.com>
Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update
Thread-Index: Ac2WZk6bkygjt2tHRWm0TALPSDGcNgAlw55wAEGmCYAAALQnAAAJZaUAAAH5cwAAAFd4gA==
Date: Fri, 21 Sep 2012 13:13:56 +0000
Message-ID: <DB308AF0-0FA7-43F5-B511-8A21B84728C1@nominum.com>
References: <CC82A1A5.29137%hesham@elevatemobile.com>
In-Reply-To: <CC82A1A5.29137%hesham@elevatemobile.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B028C3F1632D3B4580B7FCE590A44806@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:13:58 -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.   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.