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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Wed, 20 September 2017 15:52 UTC

Return-Path: <prvs=143688d48d=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 110DC13420B for <v6ops@ietfa.amsl.com>; Wed, 20 Sep 2017 08:52:59 -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 KkvxoSqCDWwe for <v6ops@ietfa.amsl.com>; Wed, 20 Sep 2017 08:52:57 -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 5B1BF1331D9 for <v6ops@ietf.org>; Wed, 20 Sep 2017 08:52:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1505922774; x=1506527574; 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=EXn7gCDEk7H6Lpmv1VpzxyHX2 4vLzocsDL2vwrZtLuY=; b=fI/dSD2iFvmeF1tsQzDFhNV/prmt8Q008RGAq7lql 9eDSMZWpdWnAnMRsDK6XP3N87etXuJuvW7x2ivpU1OkdAfEdoOAtfxMC1wbHU06C tmhruQhhIKPdx59f68X/h8u/XApCkW/DDDB6g6APwD7aTFe5h1YPUtIQh8iSj5Jo tA=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=nhzWmxykwRINRAYygE0k5WPRPivbAJgPZ5tn6nrRLfWEFD4+0LFoHM+lLebM ld5uywyn/yD5KBZRIhB2Y7PZLq8vXHjyBHVgj7zSoyLg9Ev8CWM0qWs10 BKt9Cuoi7NADeku0NT8OJRJKst1myphyis8EQujIbMFXUgtRZg8nmU=;
X-MDAV-Processed: mail.consulintel.es, Wed, 20 Sep 2017 17:52:54 +0200
X-Spam-Processed: mail.consulintel.es, Wed, 20 Sep 2017 17:52:53 +0200
Received: from [45.6.249.104] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005561387.msg for <v6ops@ietf.org>; Wed, 20 Sep 2017 17:52:52 +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:170920:md50005561387::6lzd7MSvfuH7AOBA:00001pHz
X-Return-Path: prvs=143688d48d=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: Wed, 20 Sep 2017 12:52:47 -0300
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: v6ops@ietf.org
Message-ID: <E48DDA04-C058-4992-906E-8C8BC0E102AB@consulintel.es>
Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info
References: <D5E8043B.86B21%lee@asgard.org>
In-Reply-To: <D5E8043B.86B21%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/Pwuo7Kltv2SyUhugxHsUfY33v9A>
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: Wed, 20 Sep 2017 15:52:59 -0000

>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 guess we may need a chapter update, but I really think should not be a problem and we must do that.

Saludos,
Jordi
 

-----Mensaje original-----
De: Lee Howard <lee@asgard.org>
Responder a: <lee@asgard.org>
Fecha: miércoles, 20 de septiembre de 2017, 12:45
Para: <jordi.palet@consulintel.es>, <v6ops@ietf.org>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info

    
    
    On 9/19/17, 8:23 AM, "v6ops on behalf of JORDI PALET MARTINEZ"
    <v6ops-bounces@ietf.org on behalf of jordi.palet@consulintel.es> wrote:
    
    >Hi all,
    >
    >RFC6877 (464XLAT) is an informational document.
    >...
    >
    >Can we even consider moving it to STD?
    
    
    I don’t think v6ops can promote it to Standard, or Standards Track. Our
    charter doesn’t explicitly say we’re not allowed to do standards work, but
    I would want to hear from our AD and check with 6man before promoting it.
    
    Generally, the two tests are rough consensus and multiple interoperable
    implementations. 
    
    Lee
    
    
    



**********************************************
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.