IETF Logo Mail Archive

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

Ted Lemon <Ted.Lemon@nominum.com> Fri, 21 September 2012 13:56 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 C1C7E21F8838 for <v6ops@ietfa.amsl.com>; Fri, 21 Sep 2012 06:56:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.125
X-Spam-Level:
X-Spam-Status: No, score=-106.125 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 fF1YEyfB89wJ for <v6ops@ietfa.amsl.com>; Fri, 21 Sep 2012 06:56:38 -0700 (PDT)
Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id AE2B321F8839 for <v6ops@ietf.org>; Fri, 21 Sep 2012 06:56:34 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUFxyCxD3pDk6sIOugi+hA55KgU6gk8s6@postini.com; Fri, 21 Sep 2012 06:56:34 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 65BB61B829A for <v6ops@ietf.org>; Fri, 21 Sep 2012 06:56:27 -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 5CE0019005C for <v6ops@ietf.org>; Fri, 21 Sep 2012 06:56:27 -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:56:27 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: IPv6 Ops WG <v6ops@ietf.org>
Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update
Thread-Index: Ac2WZk6bkygjt2tHRWm0TALPSDGcNgAlw55wAEGmCYAAALQnAAAJZaUAAAH5cwAAAFd4gAAAMesAAAFKEIA=
Date: Fri, 21 Sep 2012 13:56:26 +0000
Message-ID: <AB15D230-7A62-4767-84B4-CEB5F309BFC1@nominum.com>
References: <CC82A5C8.29146%hesham@elevatemobile.com>
In-Reply-To: <CC82A5C8.29146%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: <3A426EF285D71946A3D281DE307B04BB@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:56:38 -0000

On Sep 21, 2012, at 9:19 AM, Hesham Soliman <hesham@elevatemobile.com> wrote:
> 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.

It would be inappropriate for the v6ops working group to pick a winner.   We are just supposed to talk about operations.   In that context, saying "you probably ought to support DNS64" is meaningful advice, because a device that doesn't support it isn't going to be able to do DNSSEC.   This would rule out an entire transition technology, or else rule out DNSSEC.

The situation is similar for other recommendations this document makes.   Can you maybe offer some motivation for your resistance to these requirements other than "this is too strong"?

v2.23.0 | Report a Bug | By Email