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

<mohamed.boucadair@orange.com> Tue, 13 August 2013 12:39 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 CA9D021F99A1 for <softwires@ietfa.amsl.com>; Tue, 13 Aug 2013 05:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level:
X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.050, 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 LI2IpYc0LQpf for <softwires@ietfa.amsl.com>; Tue, 13 Aug 2013 05:39:31 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7B84421F862B for <softwires@ietf.org>; Tue, 13 Aug 2013 05:39:31 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 6A4F63B56AE; Tue, 13 Aug 2013 14:39:28 +0200 (CEST)
Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 49A294C015; Tue, 13 Aug 2013 14:39:28 +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 14:39:28 +0200
From: mohamed.boucadair@orange.com
To: Ole Troan <otroan@employees.org>
Date: Tue, 13 Aug 2013 14:39:27 +0200
Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt
Thread-Index: Ac6YHz3Q3V5CsCwUQgCcKKvgOC6J6QAAWAew
Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E9992@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>
In-Reply-To: <7A1D5E0A-55FE-4CF6-9444-A1BE212BB451@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.6.28.101520
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 12:39:35 -0000

Re-,

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. 

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. 

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.

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. 

I hope this issue can be resolved ASAP.

Cheers,
Med

>-----Message d'origine-----
>De : Ole Troan [mailto:otroan@employees.org]
>Envoyé : mardi 13 août 2013 14:19
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : softwires@ietf.org
>Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt
>
>Med,
>
>> It seems we agree on the provisioning part of the discussion. The MAP
>document should be sufficient in its own and should not make any assumption
>on how configuration parameters are provisioned. This can be done manually
>or dynamically (e.g., dhcp). So, any reference to a provisioning means
>should be informative, and even better be removed in favor of a single
>pointer to the unified CPE, where all this is discussed.
>>
>> Then, to the question why I'm asking for this I-D to be referenced as
>normative and not informative, the answer is that the generic bootstrapping
>logic described in the unified CPE must be followed by all softwire
>solution flavors. That's the minimum bar I see if we really want all a
>consistency to be ensured. Ideally, the CE part of all solutions should be
>documented in the unified CPE while the BR/lwAFTR parts in MAP and lw4o6
>document, but I won't ask for that.
>
>I see the relationship between the documents in the opposite way.
>there are 2-5 independent mechanisms. the unified CPE document describes
>how these can be provisioned and ensures there is some consistency between
>how a CPE can support all the mechanisms. the unified CPE document was
>never intended to drive changes in the protocol specifications of the
>mechanisms themselves.
>
>I'm not necessarily against removing the normative reference to the MAP
>DHCP draft. I am against a reference to the unified DHCP document. reason
>being as I stated above, there should not be a dependency from MAP to DHCP.
>there is also the issue of not blocking MAP document progress waiting for
>the progress of the unified CPE document.
>
>cheers,
>Ole