Re: IETF network incremental plan
JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 17 November 2016 01:06 UTC
Return-Path: <prvs=112957b6f1=jordi.palet@consulintel.es>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BF0129604 for <ietf@ietfa.amsl.com>; Wed, 16 Nov 2016 17:06:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102
X-Spam-Level:
X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, USER_IN_WHITELIST=-100] 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 mP-tm_kkrG67 for <ietf@ietfa.amsl.com>; Wed, 16 Nov 2016 17:06:32 -0800 (PST)
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 74A91129617 for <ietf@ietf.org>; Wed, 16 Nov 2016 17:06:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1479344783; x=1479949583; 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=2kfP8Y5RWflmA+OVWxaGeLpOs PQIMJVMntTSn/7r7KE=; b=hy6/bjpPzLycnZ8blwgbzspFOnLtKpp8GQuieg8dk OkxhgBN+bCXka9PZKEwDGEhlzsf38UgmpdnRlZ54Qs0LtthGmMBtPfq4yCsvkq/s SGt+mqGBhkUxU7Q5IAt+3FVYIWNMbWyZ1SpMsBrKKZeu5xezktUnq9SMUKur2zHe cY=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=r8XnCtyhyVz1rkCMChSTuzWn9OuCQDdI1jXLPFLcmZHuSgep5tWO3p2NukoE vpXFOKWQh69Q1ah/G1tcwIzk2mWcU9+rEfDEi/9stWgK/Yc+VL0fop7+h LP60e4V+bbypR+liSLrH30o41LxalvO2z3kjIUKOJsDqsLm8vALGQ0=;
X-MDAV-Processed: mail.consulintel.es, Thu, 17 Nov 2016 02:06:23 +0100
X-Spam-Processed: mail.consulintel.es, Thu, 17 Nov 2016 02:06:23 +0100
Received: from [31.133.140.36] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005226940.msg for <ietf@ietf.org>; Thu, 17 Nov 2016 02:06:22 +0100
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:161117:md50005226940::DIyG6E3S+jPqW94o:00002jPd
X-MDRemoteIP: 31.133.140.36
X-Return-Path: prvs=112957b6f1=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
User-Agent: Microsoft-MacOutlook/f.1b.0.161010
Date: Thu, 17 Nov 2016 10:06:16 +0900
Subject: Re: IETF network incremental plan
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: IETF discussion list <ietf@ietf.org>
Message-ID: <4B5823BC-1FE1-4395-A353-FE5AED8C41E3@consulintel.es>
Thread-Topic: IETF network incremental plan
References: <0C5BCD32-2D2A-42B9-8DEA-A1E1A527A8BB@consulintel.es> <m2zikzq7tg.wl-randy@psg.com>
In-Reply-To: <m2zikzq7tg.wl-randy@psg.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/TZOXWFb3v7kfGu-sQbu_sPPUEGs>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2016 01:06:34 -0000
Hi Randy, In my opinion the primary goal is to have everybody getting the work done, then testing our own protocols. Non-goal is to have individuals own stuff tested. Also, I’m speaking only about the main Wireless SSID. We can keep other SSID and the terminal room Ethernet ports, pure dual stack as we have today, which allows testing your own stuff and sorting out possible issues in case of “emergency” or major breach of our tests. NAT64 is not useful because you need to manually write down what works, what not. That’s why I’m suggesting having a first hop router with, for example a modified OpenWRT version of 464XLAT, which logs each use of CLAT and PLAT. This way we could get an automatic list of what are the apps that fail to work with IPv6, which ones work with only PLAT, and which ones need CLAT. Regards, Jordi -----Mensaje original----- De: ietf <ietf-bounces@ietf.org> en nombre de Randy Bush <randy@psg.com> Responder a: <randy@psg.com> Fecha: jueves, 17 de noviembre de 2016, 9:16 Para: Jordi Palet Martinez <jordi.palet@consulintel.es> CC: IETF discussion list <ietf@ietf.org> Asunto: Re: IETF network incremental plan last evening i was carrying a question from the noc team but my position in the mic queue was preempted by more important people. but essentially, before we make tactical decisions we would like to know what the purpose and goal of the meeting network is. o folk just want to get work done, and the net should bloody well work o i want to forward test internet futures: ipv6, auth methods, crypto, ... o i have my own stuff i want to test (which may need inbound sessions) o network? what network? in the nat64 case, are we trying to validate the well-known lists of what does not work over nat64, spotify, many vpns, ...? if it is because we think we can modify nat64 to ameliorate the problems, this would be brilliant. if we know what the goals are, we should be able to meet them. so far, the assumption is that o the primary goal of the meeting netowrk is for attendees to get work done o nats breaking applications and inbound connections would be considered as breakage o we do want to support occasional experiments, both non-disruptive and visible (remember the v6-only plenary?) o but basically, i just want my mtv randy, not speaking for anyone else ********************************************** 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 use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
- IETF network incremental plan JORDI PALET MARTINEZ
- Re: IETF network incremental plan Randy Bush
- Re: IETF network incremental plan Ted Lemon
- Re: IETF network incremental plan Paul Wouters
- Re: IETF network incremental plan JORDI PALET MARTINEZ
- Re: IETF network incremental plan Michael Richardson
- RE: IETF network incremental plan ynir.ietf
- Re: IETF network incremental plan Brian E Carpenter
- Re: IETF network incremental plan Andrew Sullivan
- Re: IETF network incremental plan David Conrad
- Re: IETF network incremental plan JORDI PALET MARTINEZ
- Re: IETF network incremental plan Benson Schliesser
- Re: IETF network incremental plan Dave Crocker
- Re: IETF network incremental plan Tim Chown
- Re: IETF network incremental plan Ted Lemon
- Re: IETF network incremental plan Dave Crocker
- Re: IETF network incremental plan Yoav Nir
- Re: IETF network incremental plan Randy Bush
- Re: IETF network incremental plan Jari Arkko
- Re: IETF network incremental plan Brian E Carpenter