Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt

<mohamed.boucadair@orange.com> Tue, 13 August 2013 13:46 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BAB11E816E for <softwires@ietfa.amsl.com>; Tue, 13 Aug 2013 06:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.21
X-Spam-Level:
X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ep-J1lW0doN for <softwires@ietfa.amsl.com>; Tue, 13 Aug 2013 06:46:17 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id AE23B21E8133 for <softwires@ietf.org>; Tue, 13 Aug 2013 06:46:16 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id CB9683B5742; Tue, 13 Aug 2013 15:46:13 +0200 (CEST)
Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id B209427C046; Tue, 13 Aug 2013 15:46:13 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Tue, 13 Aug 2013 15:46:14 +0200
From: mohamed.boucadair@orange.com
To: Ole Troan <otroan@employees.org>
Date: Tue, 13 Aug 2013 15:46:11 +0200
Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt
Thread-Index: Ac6YJQ0cbjWJ+bOeRw+p2ovLOScF4QABhlRw
Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E99B8@PUEXCB1B.nanterre.francetelecom.fr>
References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> <86841AD5-1864-4177-BEE1-4181DDE085EF@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9915@PUEXCB1B.nanterre.francetelecom.fr> <8FF0368A-D069-4BDA-9919-58FE22B81026@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9976@PUEXCB1B.nanterre.francetelecom.fr> <7A1D5E0A-55FE-4CF6-9444-A1BE212BB451@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9992@PUEXCB1B.nanterre.francetelecom.fr> <647A4750-13B0-48FC-8F1B-6851248DB941@employees.org>
In-Reply-To: <647A4750-13B0-48FC-8F1B-6851248DB941@employees.org>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.13.121523
Cc: "softwires@ietf.org" <softwires@ietf.org>
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Aug 2013 13:46:21 -0000

Re-,

It seems we are in disagreement here. Looking to have more feedback for the list.

Thanks for engaging.

Cheers,
Med

>-----Message d'origine-----
>De : Ole Troan [mailto:otroan@employees.org]
>Envoyé : mardi 13 août 2013 15:00
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : softwires@ietf.org
>Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt
>
>Med,
>
>> We both agree there is no justification to maintain the dhcp draft in the
>normative section. I consider that point closed and will wait to see this
>fixed in the document. Given that this document does not rely on how
>provisioning is achieved and given the unified CPE is where this is
>supposed to be discussed, I do still think any reference to provisioning
>should refer to the unified CPE.
>
>"not necessarily against...", is quite far from agree. ;-)
>MAP doesn't discuss the details of provisioning, but it does have a SHOULD
>to implement the MAP DHCP option. the reason for this is so that all MAP
>implementations at least support one provisioning mechanism in common.
>
>does the unified CPE propose something conflicting with the current text in
>MAP?
>(the temptation is of course to remove the normative reference, given that
>progress on a 'unified' DHCP option is slow).
>
>> It really does not make sense to not require the CE to follow the unified
>CPE behavior (in particular http://tools.ietf.org/html/draft-ietf-softwire-
>unified-cpe-01#section-3.2) if we want a minimum of coherency among the
>solutions discussed so far.
>
>that's for the unified CPE document to say.
>
>> I don't think that referring to the unified CPE draft will block the
>publication of the MAP document. This is not a technical reason BTW.
>
>no, it is not a technical reason. it is a design goal to keep MAP
>independent of the other mechanisms, i.e. it must be possible to implement
>routers that only support MAP and no other of the mechanisms.
>
>> If we maintain the same positive energy as we have started to do in the
>Atlanta meeting, I do think that we will be able to deliver all these
>documents as a package.
>
>positive energy is good! might be a little misplaced here though. ;-)
>to me it looks like we've moved the contentious parts that led to all of
>DS-lite, MAP-E, MAP-T, 4rd, LW46, Public 4over6 and no consensus to the
>DHCP/unified CPE documents.
>
>cheers,
>Ole