Re: [v6ops] Outcomes from v6ops@IETF98

Tim Chown <Tim.Chown@jisc.ac.uk> Sun, 02 April 2017 22:09 UTC

Return-Path: <tim.chown@jisc.ac.uk>
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 C2A50126B7F for <v6ops@ietfa.amsl.com>; Sun, 2 Apr 2017 15:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level:
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
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 pGYbfIgoNOnX for <v6ops@ietfa.amsl.com>; Sun, 2 Apr 2017 15:09:02 -0700 (PDT)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE167120724 for <v6ops@ietf.org>; Sun, 2 Apr 2017 15:09:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491170939; bh=ItKLYmrd5/TMDJ3Q/dsEfJIs91TQB0F4fP7ADEB8Cro=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ix+TX7vZzoLL+3XaIFg0XJkuNYHAKvcjf5AyU7tG1l7SLukQjEfsmNSlnZjJldmGVtT9DTTi9Nm0dkdT2mnsokaRj6ojKt9lBWI0Idyopvv7DScpiDJRAFvh/YY9lRIqlCXmdmbs5EfZOsPKlD15FrRN3Fpe46/UazmEKBRbo00=
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp0143.outbound.protection.outlook.com [213.199.154.143]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-58-0vydU-5PPTGy992imAk-GQ-1; Sun, 02 Apr 2017 23:08:54 +0100
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Sun, 2 Apr 2017 22:08:53 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.014; Sun, 2 Apr 2017 22:08:53 +0000
From: Tim Chown <Tim.Chown@jisc.ac.uk>
To: Fred Baker <FredBaker.IETF@gmail.com>
CC: Brian E Carpenter <brian.e.carpenter@gmail.com>, v6ops list <v6ops@ietf.org>
Thread-Topic: [v6ops] Outcomes from v6ops@IETF98
Thread-Index: AQHSqMzOl2pKnVBvckyLliBC42JP2KGvfgiAgAGzOwCAAR/ngIAAWKgA
Date: Sun, 02 Apr 2017 22:08:53 +0000
Message-ID: <E54709CA-04EE-4238-A2F0-4A553AC1D4E7@jisc.ac.uk>
References: <6C1E351B-F8B6-4BC2-890D-993A1F081226@gmail.com> <8365a4e0-d317-ed3c-59b3-2e829ff210f3@gmail.com> <F6384322-279F-4B23-8476-87C930B2ED35@jisc.ac.uk> <D42FD608-22CA-4ADD-A0ED-CC88DF3BE07B@gmail.com>
In-Reply-To: <D42FD608-22CA-4ADD-A0ED-CC88DF3BE07B@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3259)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:a88:d510:1101:2c40:904f:2602:55e7]
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:q/PCPOALp8CYr0Hz1SIw3ZCscWnWet+JwkLa13H7rDI+aSSGoAeCFnlxpmPEke30SgWvlxxw/wGVB8m1Ldg11jRiDPwy2VpBMnzcE0hThYYmLoaOqJW1UeEByHySFcCxE2Krf4J6ki99qfyHoVJFqeB05lv5krtzPcX9zoRjAsUXP4Tvs8ET2OgxaUIxl/dySs2fBVcto2vql1RpcGstWCFp7zvlzp0ExgU52yqTGVsESxghgxyUmZMu4qBHwlzGe8whaRD3o+kzULNAjGl+dkaleVBe4Hu1zcvBfTDK7On7NvKLflT4S6tv+Jx1e8uqDbzl6PukLTxMHaS1Ivguig==; 20:M5BHABpPayRaHd4RVhAGCHOmlnimYCFj8FpGCoILvqZzmT7IOc5uMkqekDkO//MLRPVdzFmRr+Xa4rBaS1O9Tjwbu4JIxED2RqgiUthmSDKrThvYmQUuDLRMcjxQQcs868JGI+hLcB3CVyx9lB0DxhBxDqsQUOrrD7r7kVzMCUE=
x-ms-office365-filtering-correlation-id: 6e8c9113-03e9-42da-3647-08d47a14d962
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1137;
x-microsoft-antispam-prvs: <AM3PR07MB1137608D67BA76765559CA58D6090@AM3PR07MB1137.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(274715658323672);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137;
x-forefront-prvs: 02652BD10A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39410400002)(39840400002)(39450400003)(24454002)(377454003)(39060400002)(38730400002)(53936002)(3660700001)(110136004)(6116002)(102836003)(5660300001)(6246003)(99286003)(7736002)(4326008)(305945005)(6506006)(42882006)(6306002)(2950100002)(8936002)(6916009)(54906002)(74482002)(86362001)(6512007)(93886004)(6436002)(8676002)(189998001)(33656002)(5250100002)(81166006)(25786009)(50226002)(53546009)(229853002)(36756003)(5890100001)(57306001)(83716003)(3280700002)(2906002)(82746002)(2900100001)(6486002)(50986999)(76176999)(32563001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <30A01FBBC7E47C4B9549561A539383BD@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2017 22:08:53.0015 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137
X-MC-Unique: 0vydU-5PPTGy992imAk-GQ-1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/JRgBXH_80VGJcGETn8yeCBlzCcA>
Subject: Re: [v6ops] Outcomes from v6ops@IETF98
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: Sun, 02 Apr 2017 22:09:05 -0000

Hi Fred,

> On 2 Apr 2017, at 17:51, Fred Baker <FredBaker.IETF@gmail.com> wrote:
> 
> 
>> On Apr 1, 2017, at 4:41 PM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
>>>> One question I intended to ask and didn't get to was the appropriateness of an interim meeting, perhaps in mid-May. It would primarily address draft-ietf-v6ops-ula-usage-considerations and draft-petrescu-v6ops-ipv6-power-ipv4, and potentially draft-ietf-v6ops-design-choices if it is updated. There is an argument for leaving these to IETF 99, and potentially booking a second slot for that discussion. Your opinions?
>> 
>> Seconded. Is the intention a physical or virtual meeting, or both?
> 
> I was thinking in terms of webex or equivalent, somewhere in May 8-18. If folks want to have a meeting, I have to announce it 30 days in advance, which means I'll send a doodle poll and we'll figure out when to have it during this coming week. To my small mind, June is late enough that we may as well delay for July.

OK; as Jordi says, I doubt many people would travel just for this. Mid-to-late May sounds right. The age-old problem is picking which part of the world to inconvenience the most; I guess looking at the locale of the bulk of the authors is the fairest way? 

> My *guess* at an agenda in July includes
>    draft-ietf-v6ops-ula-usage-considerations if needed
>    draft-ietf-v6ops-design-choices if updated and needed
>    draft-petrescu-v6ops-ipv6-power-ipv4 if needed
> 
>    draft-ietf-v6ops-happy-eyeballs-update
>    draft-ietf-v6ops-rfc7084-bis
>    draft-ietf-v6ops-ipv6rtr-reqs
> 
> Plus possible additional work submitted between now and then. Note the "if needed"; they might be an argument for a second slot if we don't have an interim meeting, and if we do have one, would only be on the agenda if updated and there is working group interest.

I’d assume we have a draft cutoff one week before the meeting so update could be discussed?  Worst case we’d then ensure an extra cycle of work before Prague.

> If you look at https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ula-usage-considerations-02.txt, you will see that the authors have done some pretty heavy-duty changes to the document. I think the question would be (and this could be in email or verbally) what additional changes people would like to see. I'd invite a thorough review of the document as it stands. I'll note that "let's deprecate ULA or tell people to never use it" doesn't fit with current operational practice; when my phone is not attached to a WiFi, the DNS address my provider offers me is a ULA address. "Don't NAT", fine, but "don't ULA" as a blanket statement is inconsistent with operational practice in some providers, and "ULA implies NAT" is just silly. It implies that the systems so addressed are not normally advertised in BGP, nothing more and nothing less.
> 
> draft-petrescu-v6ops-ipv6-power-ipv4 is a brand new draft, slipped in just under the wire. The first question is whether the working group is interested; there wasn't time for that discussion to happen before IETF 98. If we ARE interested, what do we think of it?

It would be more interesting if the reasons for the additional power consumption were identified and discussed - there’s no sign of this that I can see in the document - are there recommendations for reducing power consumption for IPv6, different to IPv4?

> draft-ietf-v6ops-design-choices didn't get updated for this meeting, and sooner or later will simply drop off radar. Folks have periodically said that they find it interesting and potentially useful, but the authors have largely run out of steam. So at least part of the question is "what is the future for this draft?". 

I think there’s good material, well written, in design-choices; it would be a shame to lose it. It would complement draft-ali-ipv6rtr-reqs quite nicely. I note the first -00 was nearly 5 years ago though!

Tim