Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt

<david.binet@orange.com> Mon, 19 November 2012 10:30 UTC

Return-Path: <david.binet@orange.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 C0E5621F8564 for <v6ops@ietfa.amsl.com>; Mon, 19 Nov 2012 02:30:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.822
X-Spam-Level:
X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
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 q8rVh6OeWKM5 for <v6ops@ietfa.amsl.com>; Mon, 19 Nov 2012 02:30:50 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6757821F849E for <v6ops@ietf.org>; Mon, 19 Nov 2012 02:30:49 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1F9C018C3F4; Mon, 19 Nov 2012 11:30:49 +0100 (CET)
Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D9BDD35C058; Mon, 19 Nov 2012 11:30:48 +0100 (CET)
Received: from PUEXCB1A.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Mon, 19 Nov 2012 11:30:46 +0100
From: <david.binet@orange.com>
To: Lorenzo Colitti <lorenzo@google.com>
Date: Mon, 19 Nov 2012 11:30:45 +0100
Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt
Thread-Index: Ac3GPSYjHiUrcAQjTxuv+kW78tjtGgAArGOA
Message-ID: <32082_1353321049_50AA0A58_32082_2067_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56FF4@PUEXCB1A.nanterre.francetelecom.fr>
References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> <CAKD1Yr0PcobuWwu+Dp36NHaFRyinD1SRV0WPk792h9EwwsuFmQ@mail.gmail.com> <17547_1353319026_50AA0272_17547_9460_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56F7B@PUEXCB1A.nanterre.francetelecom.fr> <CAKD1Yr205BrFYDRz5DqYaGJvFVhTm-YNWQPbuSD0t3rKN=wj+w@mail.gmail.com>
In-Reply-To: <CAKD1Yr205BrFYDRz5DqYaGJvFVhTm-YNWQPbuSD0t3rKN=wj+w@mail.gmail.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_1B2E7539FECD9048B261B791B1B24A7C3EF5B56FF4PUEXCB1Anante_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.19.100316
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt
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: Mon, 19 Nov 2012 10:30:51 -0000


________________________________
De : Lorenzo Colitti [mailto:lorenzo@google.com]
Envoyé : lundi 19 novembre 2012 11:03
À : BINET David OLNC/OLN
Cc : BOUCADAIR Mohamed OLNC/OLN; IPv6 Ops WG
Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt

On Mon, Nov 19, 2012 at 6:57 PM, <david.binet@orange.com<mailto:david.binet@orange.com>> wrote:
And I do not understand the comment about the need to remove some requirements and to provide a link to RFC3316bis document. I do not understand why a RFCbis draft was proposed if the specifications were already present in draft-binet-* document.
Because that draft properly updates RFC3316. This document does not update RFC3316, it's something completely different.
[[david]] You are right. It is different and the goal is to get a document where we can have all IPv6 specifications.
Besides, I do not have the feeling that there was some demand for a RFC3316 update whereas there was some support for a document providing an IPv6 profile, as proposed in draft-binet-.
Second, most of this document attempts to standardize feature sets, not protocols or interoperability. I'm not sure this is is in scope for the IETF, and even more so for an operations group inside the IETF.
[[david]] It is your opinion but as operator, it is something which is very important and there is a lack in standardisation documents where some IPv6 profile is defined. We receive a lot of support about such specifications.
Does the IETF define an IPv4 profile? If not, why not?
[[david]] As an operator, I would say such document would not be required if we had IPv6 terminals. But it is not the case and we need to get such reference even if it is not our only action to get such devices.
Does the IETF define an IPv6 profile for CPE ? Yes. Now, there is RFC6204.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.