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

Lee Howard <lee@asgard.org> Fri, 22 September 2017 18:48 UTC

Return-Path: <lee@asgard.org>
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 50900132697 for <v6ops@ietfa.amsl.com>; Fri, 22 Sep 2017 11:48:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] 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 AJWRP9OBjm_I for <v6ops@ietfa.amsl.com>; Fri, 22 Sep 2017 11:48:50 -0700 (PDT)
Received: from atl4mhob01.registeredsite.com (atl4mhob01.registeredsite.com [209.17.115.39]) (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 AF839134597 for <v6ops@ietf.org>; Fri, 22 Sep 2017 11:48:50 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob01.registeredsite.com (8.14.4/8.14.4) with ESMTP id v8MImlY2031564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <v6ops@ietf.org>; Fri, 22 Sep 2017 14:48:48 -0400
Received: (qmail 21579 invoked by uid 0); 22 Sep 2017 18:48:47 -0000
X-TCPREMOTEIP: 72.221.14.183
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@72.221.14.183) by 0 with ESMTPA; 22 Sep 2017 18:48:47 -0000
User-Agent: Microsoft-MacOutlook/14.7.2.170228
Date: Fri, 22 Sep 2017 14:48:44 -0400
From: Lee Howard <lee@asgard.org>
To: jordi.palet@consulintel.es, "v6ops@ietf.org WG" <v6ops@ietf.org>
Message-ID: <D5EAD0A6.8715F%lee@asgard.org>
Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info
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> <20170921223305.B72A8878E716@rock.dv.isc.org> <CAKD1Yr13ijKCB_71_2vMyGurc3-kSraLJycGxZwf121tjp8u1Q@mail.gmail.com> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <D5EA8233.87034%lee@asgard.org> <D5EAC4D0.870DE%lee@asgard.org> <C881CD21-DE62-4450-A644-181C884128AB@consulintel.es>
In-Reply-To: <C881CD21-DE62-4450-A644-181C884128AB@consulintel.es>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/wOVmS4f7NVRgFeKB0jhh4Vtpe1w>
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 18:48:53 -0000


On 9/22/17, 2:22 PM, "v6ops on behalf of JORDI PALET MARTINEZ"
<v6ops-bounces@ietf.org on behalf of jordi.palet@consulintel.es> wrote:

>Hi Lee,
>
>See below in-line.
>
>Regards,
>Jordi
> 
>
>-----Mensaje original-----
>De: v6ops <v6ops-bounces@ietf.org> en nombre de Lee Howard
><lee@asgard.org>
>Responder a: <lee@asgard.org>
>Fecha: viernes, 22 de septiembre de 2017, 14:56
>Para: Lee Howard <lee@asgard.org>
>CC: "v6ops@ietf.org WG" <v6ops@ietf.org>
>Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info
>
>    As to the original question, I have a couple of questions:
>    
>    1. What is gained by promoting rfc6877 "464XLAT: Combination of
>Stateful
>    and Stateless Translation”?  Regardless of whether the correct
>promotion
>    path is BCP or Proposed Standard, what is the goal?
>
>[Jordi] My point is: I understand that when 464XLAT was proposed, it was
>not considered at the same level as other transition mechanisms, which
>are, from the start, standards track. Now that this is the most
>successful (in terms of number of users vs. all the other transition
>mechanisms), in my opinion there is no reason to discriminate it. So,
>either we drop to informational all the transition mechanisms that have
>so much lower degree of success or even to historic or deprecated those
>that are not used. Is a matter of fairness and recognize the reality.

Well, rfc6877 doesn’t define a new protocol, it describes a way that
existing technologies could meet a need. I’m trying to read it as a
Technical Specification as defined by rfc2026, and I don’t see how it fits.

Who is discriminating against the most successful mechanism based on its
document track?

>    
>    2. rfc2026 “The Internet Standards Process”  says a BCP is the "best
>    current thinking on a statement of principle or on what is believed
>to be
>    the best way to perform some operations.”  What principle or what
>    operations is 464xlat best for?
>    
>[Jordi] Well, I was suggesting standards track, not BCP. So not sure how
>to read this question myself. Actually, I’ve drafted already (started two
>months ago, and not related at all to this discussion, but for lack of
>time availability, haven’t completed it yet, hopefully can have it early
>next week) a BCP which initially I’ve titled “464XLAT Deployment
>Guidelines in Operator Networks”. The idea come out after we had the
>discussion of deploying at the IETF network 464XLAT instead of just
>NAT64. In this document I’m describing how, according to my experience
>(and hopefully inputs from others once a first version is published),
>464XLAT is being deployed in both cellular and non-cellular networks.

Maybe I should have also asked the question, “How does rfc6877 meet the
standard of an Internet Standard according to rfc2026?”

Lee