Re: [Softwires] map-t to proposed standard rather than experimental
Rémi Després <despres.remi@laposte.net> Thu, 13 November 2014 13:59 UTC
Return-Path: <despres.remi@laposte.net>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A044F1A8746 for <softwires@ietfa.amsl.com>; Thu, 13 Nov 2014 05:59:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.249
X-Spam-Level:
X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 VQyOQfFykc8U for <softwires@ietfa.amsl.com>; Thu, 13 Nov 2014 05:59:18 -0800 (PST)
Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id 251161A8742 for <softwires@ietf.org>; Thu, 13 Nov 2014 05:59:17 -0800 (PST)
Received: from filter.sfr.fr (localhost [78.193.136.169]) by msfrf2419.sfr.fr (SMTP Server) with ESMTP id D8F8570000B5; Thu, 13 Nov 2014 14:59:16 +0100 (CET)
Authentication-Results: sfrmc.priv.atos.fr; dkim=none (no signature); dkim-adsp=none (no policy) header.from=despres.remi@laposte.net
Received: from [192.168.0.21] (unknown [78.193.136.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by msfrf2419.sfr.fr (SMTP Server) with ESMTP id 7746370000B1; Thu, 13 Nov 2014 14:59:16 +0100 (CET)
X-SFR-UUID: 20141113135916488.7746370000B1@msfrf2419.sfr.fr
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Rémi Després <despres.remi@laposte.net>
In-Reply-To: <89DAC716-3472-44DE-9708-0016B7CBA4EE@nominum.com>
Date: Thu, 13 Nov 2014 14:59:14 +0100
Message-Id: <FA81A113-0A92-4794-B84E-2121DFBB9625@laposte.net>
References: <04453287-AE2D-47DF-80FF-2C717AE1B23E@nominum.com> <0131B885-9F7F-4F44-956C-91066AE512EA@laposte.net> <89DAC716-3472-44DE-9708-0016B7CBA4EE@nominum.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
X-Mailer: Apple Mail (2.1878.6)
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/zu8zoR2JusWxxkLMh0E8_IFfkAs
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] map-t to proposed standard rather than experimental
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 13 Nov 2014 13:59:21 -0000
Le 13 nov. 2014 à 01:46, Ted Lemon <Ted.Lemon@nominum.com> a écrit : > On Nov 11, 2014, at 11:46 PM, Rémi Després <despres.remi@laposte.net> wrote: >> What makes objections to become blocking may be unclear, but I hope that the above will be enough for the WG to maintain its old and wise consensus. > > For an objection to be blocking, you should be able to say that some interoperability issue exists or is thought to exist in the document that needs to be explored, and that is the reason for the experiment. Otherwise the presumption is that an experimental document could be promoted to standards track at any time after publication. Thanks for the clarification. 1. Concerning interoperability, can a MAP-T-only CPE communicate with a MAP-E only DTE? AFAIK, the answer is a clear NO. 2. Note that, although MAP-E being THE standard, necess , any ISP that provides CPEs to all its customers can deploy any workable solution of its own for the same purpose. - If the design is right, it can work perfectly. - Two such solutions are specified in IETF for this (in addition to the standard itself), with different pros and cons (MAP-T and 4rd). For ISPs whose CPEs may be supplied by customers themselves, interworking between CPEs depends on all of them supporting only THE standard. This becomes supporting ALL THE standards if there are several. This being said, if the WG consensus becomes that 2 standards are preferred to 1, my point is that it should be done consciously. Besides, my personal view remains that, for a given purpose, 1 standard is better than 2. Regards, RD
- [Softwires] map-t to proposed standard rather tha… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… Rajiv Asati (rajiva)
- Re: [Softwires] map-t to proposed standard rather… B.Nagaraj
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… Ida Leung
- Re: [Softwires] map-t to proposed standard rather… Mallette, Edwin J.
- Re: [Softwires] map-t to proposed standard rather… Mallette, Edwin J.
- Re: [Softwires] map-t to proposed standard rather… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… HALLE Fabrice
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… Xing Li
- Re: [Softwires] map-t to proposed standard rather… Petersen, Matt J
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… Ole Troan
- Re: [Softwires] map-t to proposed standard rather… Wojciech Dec
- Re: [Softwires] map-t to proposed standard rather… Xing Li
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Tom Taylor
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Tom Taylor
- Re: [Softwires] map-t to proposed standard rather… Rémi Després
- Re: [Softwires] map-t to proposed standard rather… Ted Lemon
- Re: [Softwires] map-t to proposed standard rather… Rémi Després