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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Fri, 22 September 2017 18:24 UTC

Return-Path: <prvs=1438bb095a=jordi.palet@consulintel.es>
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 535E81342F3 for <v6ops@ietfa.amsl.com>; Fri, 22 Sep 2017 11:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es
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 N94qUOrOZojt for <v6ops@ietfa.amsl.com>; Fri, 22 Sep 2017 11:24:06 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D6B134584 for <v6ops@ietf.org>; Fri, 22 Sep 2017 11:22:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506104563; x=1506709363; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=a8GvVvgSk/pfE3YfThLR61GKo drc0g30BUFGCD6uick=; b=snnhPd/R4X57+2X1JkdeG575YL6X8Jja6m8xF7ckR cPGhOWs2zWMs1JpV4ztg6JTjGOWudOZWY+qaVpRtpj44uhco2vCPzc5JrRUWbMAc 8W1bGWNWPamya/ZY71bCH+KdCGUfToES3sFCTLeND+88jzEM4Nb2KMLnaycb0jCc vE=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=OVY9EAINxNlmuKE6rjYirX5GB5tOnzNvYd3X2dstHBkcp2aDQGxn7pDQSGES eIzpJHgH5hstcrzoFzssWm5O9Ul5AL0S3+SIokQx9T5TEzTon2STpR2rF zn0auxBeA9nqO04JZ7/LHh+yIxg7YTFCOsiaHA9ZJ3rSPiB2lQNKHE=;
X-MDAV-Processed: mail.consulintel.es, Fri, 22 Sep 2017 20:22:43 +0200
X-Spam-Processed: mail.consulintel.es, Fri, 22 Sep 2017 20:22:42 +0200
Received: from [45.6.249.44] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005563324.msg for <v6ops@ietf.org>; Fri, 22 Sep 2017 20:22:42 +0200
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:170922:md50005563324::CyzxJcpYVsLw3PLZ:00007pBw
X-Return-Path: prvs=1438bb095a=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.26.0.170902
Date: Fri, 22 Sep 2017 15:22:35 -0300
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: "v6ops@ietf.org WG" <v6ops@ietf.org>
Message-ID: <C881CD21-DE62-4450-A644-181C884128AB@consulintel.es>
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>
In-Reply-To: <D5EAC4D0.870DE%lee@asgard.org>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/AogTBRhV5faMeXNPiIZq0CB7t5Y>
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:24:08 -0000

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.
    
    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.
   
    The chairs are working out how to handle this request, and answers to
    these questions will help us.
    
    Thanks,
    
    Lee
    
    
    
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.