Re: [v6ops] reclassify 464XLAT as standard instead of info

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 22 September 2017 04:44 UTC

Return-Path: <alexandre.petrescu@gmail.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 975C6133075 for <v6ops@ietfa.amsl.com>; Thu, 21 Sep 2017 21:44:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level:
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 l6axYJHc8txJ for <v6ops@ietfa.amsl.com>; Thu, 21 Sep 2017 21:44:00 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8883F133071 for <v6ops@ietf.org>; Thu, 21 Sep 2017 21:44:00 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8M4hwdZ108394 for <v6ops@ietf.org>; Fri, 22 Sep 2017 06:43:58 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3ACE12014DA for <v6ops@ietf.org>; Fri, 22 Sep 2017 06:43:58 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 31128200FA0 for <v6ops@ietf.org>; Fri, 22 Sep 2017 06:43:58 +0200 (CEST)
Received: from [132.166.84.3] ([132.166.84.3]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8M4hvbq015128 for <v6ops@ietf.org>; Fri, 22 Sep 2017 06:43:57 +0200
To: v6ops@ietf.org
References: <D5E8043B.86B21%lee@asgard.org> <E48DDA04-C058-4992-906E-8C8BC0E102AB@consulintel.es> <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <de6b9aac-a3cc-0915-77c7-9fb880c3a16a@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <61549b08-a85d-cf88-3a61-69e67480333d@gmail.com>
Date: Fri, 22 Sep 2017 06:43:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <de6b9aac-a3cc-0915-77c7-9fb880c3a16a@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/muje0gv0HYySigyGb-gkbvORmU4>
Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Sep 2017 04:44:04 -0000


Le 21/09/2017 à 22:39, Brian E Carpenter a écrit :
> On 21/09/2017 20:05, Ole Troan wrote:
>>>>>>  From my perspective, there are multiple interoperable specs. We have several CLAT client implementations/vendors, from different vendors, and they work fine in the same and different operators and interoperate with different NAT64 and DNS64 vendors/implementations.
>>>>>
>>>>> What I’m not sure is, because 464XLAT is basically RFC6145 (SIIT) + RFC6146 (Stateful NAT64) and also can use RFC6147 (DNS64), which are already Standards track, if we need also to move them to STD in that case, etc.
>>>>
>>>> I'll repeat myself earlier. Looking at the definitions of the terms, there is no reason it can't or shouldn't be BCP, which our charter does allow us to do, and which is a one-shot standard more appropriate to the case (IMHO). If you want it to be a standardard, a BCP is a standard. Let's advance it to BCP.
>>>
>>> I think there’s an argument for this.
>>>
>>> But there will be people who will argue that encapsulation is the ‘best’ practice.  Is there scope for a BCP by translation and a BCP by encapsulation?  Or would the BCP say NAT64/DNS64/464XLAT is the best way to serve nodes in an IPv6-only network?
>>>
>>> With IPv4 NAT, the IETF didn’t define specific NAT mechanisms, so we ended up with many varieties, with different properties. There’s an argument also I think to nail down one single best translation approach.
>>
>> Yes, I do wonder in what alternate universe the IETF consensus is that best current practice is NAT44 -> NAT46 -> NAT64 + DNS64. ;-)
> 
> We have a problem in that people confuse "a standard" with "the standard" and
> "a best current practice" with "the best current prcatice". But in the end that's
> just a matter of wording in the Abstract and Introduction. We say: if you want
> to run a pure IPv6 network service while supporting IPv4-only clients and servers,
> and do not wish to use any form of IPv4-in-IPv6 tunnel, here is a good way to do it.
> 
> That does sound like a BCP to me.

I could agree if it were "ABCP" for _a_ BCP.

But I am afraid in English you cant say "a Best", there is only "one 
Best" and maybe "a Better".

WE dont say several "Bests".

You may know better, though.

Alex

> 
>      Brian
> 
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>