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

<mohamed.boucadair@orange.com> Fri, 30 January 2015 08:07 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE9B1A89B3 for <v6ops@ietfa.amsl.com>; Fri, 30 Jan 2015 00:07:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOUxir2QP-Do for <v6ops@ietfa.amsl.com>; Fri, 30 Jan 2015 00:07:51 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09DE01A899A for <v6ops@ietf.org>; Fri, 30 Jan 2015 00:07:51 -0800 (PST)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 76D6B374169; Fri, 30 Jan 2015 09:07:49 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id BD5E815809E; Fri, 30 Jan 2015 09:07:48 +0100 (CET)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Fri, 30 Jan 2015 09:07:48 +0100
From: <mohamed.boucadair@orange.com>
To: James Woodyatt <jhw@nestlabs.com>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZzW83IAgACD6oCAANm6QA==
Date: Fri, 30 Jan 2015 08:07:48 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933004902567@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <B7D61F30-BAC4-4BE0-A5FD-1D4BD4652E55@employees.org> <CADhXe52bTnPXz3H6kxscKSsutd-ZKx-TCTP2sh=YdbeerArT3g@mail.gmail.com>
In-Reply-To: <CADhXe52bTnPXz3H6kxscKSsutd-ZKx-TCTP2sh=YdbeerArT3g@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933004902567OPEXCLILM23corp_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/gGeRAR6YQ2BHqkhLCUvvd_shhfI>
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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, 30 Jan 2015 08:07:53 -0000

Dear James,

Your proposed wording is OK with me.

I implemented it in my local copy, thanks.

Cheers,
Med

De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de James Woodyatt
Envoyé : jeudi 29 janvier 2015 21:07
À : IPv6 Ops WG
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

Additionally—

Editorial: the section for Security Considerations currently says this:

Security-related considerations that apply when the cellular device provides LAN features are specified in [RFC6092<https://tools.ietf.org/html/rfc6092>]2>].

This sentence is a bit awkward— but more importantly, RFC 6092 is not a specification, and the chain of citation that lead to its reference here is far from clear.  I suggest the following wordier but more helpful replacement:

In the case of cellular devices that provide LAN features, compliance with L_REC#2 entails compliance with RFC 6204, which in turn recommends compliance with Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service [RFC6092<https://tools.ietf.org/html/rfc6092>]2>]. Therefore, the security considerations in section 6 of that document are relevant. In particular, it bears repeating here that the true impact of stateful filtering may be a reduction in security, and that IETF make no statement, expressed or implied, as to whether using the capabilities described in any of these documents ultimately improves security for any individual users or for the Internet community as a whole.

p.s. I also share all of Lorenzo's other specific concerns about this draft, as well as his broad general objections.


--
james woodyatt <jhw@nestlabs.com<mailto:jhw@nestlabs.com>>
Nest Labs, Communications Engineering