Re: [v6ops] New drafts

otroan@employees.org Fri, 16 June 2017 17:53 UTC

Return-Path: <otroan@employees.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 F344D129B48 for <v6ops@ietfa.amsl.com>; Fri, 16 Jun 2017 10:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 unkNkCx4bi9h for <v6ops@ietfa.amsl.com>; Fri, 16 Jun 2017 10:53:14 -0700 (PDT)
Received: from accordion.employees.org (cowbell.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89DC129B39 for <v6ops@ietf.org>; Fri, 16 Jun 2017 10:53:13 -0700 (PDT)
Received: from h.hanazo.no (77.16.70.76.tmi.telenormobil.no [77.16.70.76]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 85CBC2D4FD1; Fri, 16 Jun 2017 17:53:10 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 11FCED475BBC; Fri, 16 Jun 2017 08:34:41 +0200 (CEST)
From: otroan@employees.org
Message-Id: <6E1501F8-7399-4095-99CA-811B222B9D87@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_DD68E61D-B899-4DD5-85CC-88EA5D6057AE"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 16 Jun 2017 08:34:40 +0200
In-Reply-To: <1D8A289A-86C2-47C9-90E2-A36E3BB414D6@gmail.com>
Cc: IPv6 Operations <v6ops@ietf.org>
To: Fred Baker <fredbaker.ietf@gmail.com>
References: <1D8A289A-86C2-47C9-90E2-A36E3BB414D6@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/9od7Ddb33he9WyVlMizfIhsNJ_4>
Subject: Re: [v6ops] New drafts
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, 16 Jun 2017 17:53:16 -0000

> We have several new drafts that the chairs would like working group discussion on, if only to gauge interest. Jen sent a note regarding hers a moment ago. Jordi has, following feedback, divided 70844bis, and we are looking for commentary on each.
> 
> 	2017-06-14	draft-linkova-v6ops-conditional-ras
> 	2017-06-12	draft-palet-v6ops-rfc7084-bis-transition
> 	2017-06-11	draft-palet-v6ops-rfc7084-bis2
> 	2017-06-11	draft-palet-v6ops-rfc7084-bis4-hncp
> 
> https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis
>  "Basic Requirements for IPv6 Customer Edge Routers", Jordi Palet,
>  2017-06-12
> 
> https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis-transition
>  "Transition Requirements for IPv6 Customer Edge Routers", Jordi Palet,
>  2017-06-12
> 
> https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis2
>  "Minimum Requirements for IPv6-only Customer Edge Routers", Jordi Palet,
>  2017-06-11
> 
> https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis4-hncp
>  "Basic Requirements for IPv6 Customer Edge Routers with HNCP", Jordi Palet,
>  2017-06-11

I would prefer to see two IPv6 CE documents.
One updated 7084 with HNCP requirements and the transition mechanisms taken out.
One only for the transition mechanisms. Although that might have some overlap with draft-ietf-softwire-unified-cpe

The first is closest to Jordi's rfc7084-bis4-hncp (although there are not HNCP requirements there yet).
The second rfc7084-bis-transition. Although I have issues with the approach of recommending all options and not making a choice. When the IETF leaves it to the market to decide, because it cannot reach consensus, then we should consider that, given this is the closest thing we have to a "recommendations to the market" style document.

I also have issues with the author of these documents replacing the original author set with himself in the documents.

Cheers,
Ole