[v6ops] [*SPAM* Score/Req: 3.5/3.3] possible path forward with RFC7084 and transition/other stuff

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Fri, 21 July 2017 07:48 UTC

Return-Path: <prvs=13753e1d62=jordi.palet@consulintel.es>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4B202129A92 for <v6ops@ietfa.amsl.com>; Fri, 21 Jul 2017 00:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 16TqaUphUqTc for <v6ops@ietfa.amsl.com>; Fri, 21 Jul 2017 00:48:24 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56CF112714F for <v6ops@ietf.org>; Fri, 21 Jul 2017 00:48:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500623302; x=1501228102; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:Mime-version:Content-type:Content-transfer-encoding: Reply-To; bh=Trr+WNmuCOb/ExZA1pUnedSBQQ5tdWX5tEeMgxSR6RQ=; b=OND LPrxls48N4zcmSS+VRyi/MWHI2m0RzUve3aS9krKmcuczsQyLxbxqvpeLIkXHJT9 RMM6rniLJo7nYOM2R8i9MBZ9zJn4EN8+1z1TDxWk+D/AxOjx4gBAiFqwIIyc5am1 +WBW/iZpKAxJkGRVu+L7ndfOSa3Cz0LsqIufMNlk=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=afKe9eXAeSu1B0ZFH4iv9p+LnYfaFLvX5ZeQX8qYn5JDSIR4RCG2fmcpBjcb y5KPjBSkMe/qUyzSHTJNjEfDBqyLz4JNFTLrHxWZhty3DzN942UIQkaZw x25krLxnpBcaKU54RYOgC3N20fQ3Dc1U7S6e+RABE+Fb+OZ0dh8wC0=;
X-MDAV-Processed: mail.consulintel.es, Fri, 21 Jul 2017 09:48:22 +0200
X-Spam-Processed: mail.consulintel.es, Fri, 21 Jul 2017 09:48:20 +0200
Received: from [] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005482596.msg for <v6ops@ietf.org>; Fri, 21 Jul 2017 09:48:19 +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:170721:md50005482596::D1lbT8YJgDMgiG9D:00003K9a
X-Return-Path: prvs=13753e1d62=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Fri, 21 Jul 2017 09:48:15 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: v6ops@ietf.org
CC: Tim Chown <Tim.Chown@jisc.ac.uk>, "STARK, BARBARA H" <bs7652@att.com>, james woodyatt <jhw@google.com>
Message-ID: <1AE6D99E-DA24-486E-9735-5E42F60CE5A0@consulintel.es>
Thread-Topic: possible path forward with RFC7084 and transition/other stuff
X-Priority: 2
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
X-Spam-Prev-Subject: possible path forward with RFC7084 and transition/other stuff
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/4uj8rPo9i3edZoF7A6XNASKRoAI>
Subject: [v6ops] [*SPAM* Score/Req: 3.5/3.3] possible path forward with RFC7084 and transition/other stuff
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, 21 Jul 2017 07:48:26 -0000

Hi all,

We will like to know the WG opinions on this.

(I’m sending this email after checking with the WG chairs if they agree on it)

Yesterday during the bits-N-bytes here in Prague, a few of us (in copy), have a chat about a possible path forward with the RFC7084-bis and related docs.

If I understood correctly, we somehow agreed that a possible path is (let’s call this CHOICE 1):
1) Not change/update the existing RFC7084.
2) Use my “Transition Requirements for IPv6 Customer Edge Routers” document (draft-palet-v6ops-rfc7084-bis-transition-00) as a starting point, which “extend” the requirements of RFC7084 towards supporting actual world transition requirements.
3) In this updated document, the transition requirements can then be a MUST, so vendors take it seriously.
4) I will include the reference to RFC8026 (some more text, as this reference is already in all my docs regarding this topic), so there is a “flow” of how the pair “ISP-CE” can get working IPv6 and then IPv4 if it is available from the ISP “as a service”. I think this can have also what Fred was suggesting as “IPv6 must be on by default”, right?

CHOICE 2 (to make it clear, my own toughs after waking up this morning, not discussed with the other folks yesterday):
Same as choice 1 above, but include also support for HNCP and may be something else if we believe it is required during the development of this document (for example it seems clear that if we offer IPv4 as a service, because actual multicast-based IPTV services run on IPv4, we need to keep supporting that on top of an IPv6-only access).
So then the document will be renamed to something such as “Transition and extended requirements for IPv6 CE routers”.

Tim, Barbara, James, can you confirm if I got right choice 1, or misunderstood/missed anything?

WG participants, could you provide your view on those two options?

Tim (Winters), could you tell from the perspective of the IPv6 Ready Logo Program your view on those two approaches?

It will be nice to be able to double check all the inputs from yesterday v6ops sessions, but looking at the etherpad I can’t see them, so may be the note takers were using something else. It is possible to access the minutes already someway? I will like to start working on this immediately …



IPv4 is over
Are you ready for the new Internet ?
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.