Re: IPv6 options defined outside of 6man

Tim Chown <Tim.Chown@jisc.ac.uk> Tue, 22 November 2016 13:15 UTC

Return-Path: <tim.chown@jisc.ac.uk>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD751295EF for <ipv6@ietfa.amsl.com>; Tue, 22 Nov 2016 05:15:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.111
X-Spam-Level:
X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com
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 p2obIplLLxNR for <ipv6@ietfa.amsl.com>; Tue, 22 Nov 2016 05:15:22 -0800 (PST)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.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 5960D129DF5 for <ipv6@ietf.org>; Tue, 22 Nov 2016 05:15:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UxiLYNo9T3OZ7B6ysyf8qtWvl5DGRzgNVBhiHX2ZIo8=; b=WYWy8t3EM9KmuKRgm5r6OTNOW8Ts2bxpteUk+ABeBoVMtOGkQPCQXgc1Ye3j0V7YiQi06dg4kEhBUSvLLt9HFwf+VNcMZtu8hDlOTE1IO433CyF0kLw50YvgM8mlRFopjuAtrtsIOOYa4akhU952sslAvculZZDS758e5cg5WE4=
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0248.outbound.protection.outlook.com [213.199.154.248]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-53-Qh78zj-1PF-AVEN6A_1Yug-1; Tue, 22 Nov 2016 13:15:04 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Tue, 22 Nov 2016 13:15:02 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9ee:f373:b37e:9c77]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9ee:f373:b37e:9c77%15]) with mapi id 15.01.0734.007; Tue, 22 Nov 2016 13:15:02 +0000
From: Tim Chown <Tim.Chown@jisc.ac.uk>
To: "t.petch" <ietfc@btconnect.com>
Subject: Re: IPv6 options defined outside of 6man
Thread-Topic: IPv6 options defined outside of 6man
Thread-Index: AQHSP+HTOwKJRpIstE+05booqSBH/aDd8RkAgAVH3ICAABBvAIABjJVOgAAvGoA=
Date: Tue, 22 Nov 2016 13:15:02 +0000
Message-ID: <6C6D8579-AA05-4C1C-B20D-F0D315213458@jisc.ac.uk>
References: <alpine.DEB.2.02.1611160858330.14320@uplift.swm.pp.se> <7DAEC99E-D17F-4BFD-9747-F4B7E423FCDD@jisc.ac.uk> <b7915bc6-c024-293d-9eef-b018db33a85f@bogus.com> <C5A5BEA5-A371-440F-A111-A62EF9B6674C@jisc.ac.uk> <02a401d244aa$5f3c92a0$4001a8c0@gateway.2wire.net>
In-Reply-To: <02a401d244aa$5f3c92a0$4001a8c0@gateway.2wire.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3251)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [194.82.140.195]
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:JbMsFZlHkWurTJmqQcXnkLxY7mYTXtvsQvleVpGOMU1NaR9OiOTirWC0z9cG/fNUqDBa125gzgDaAQY+vZGPvCBP3zlDWW7uoS0qPYjlQ6iA+9m7cJjEPBxFK7D1dNDJCtH4J8W8KgVSoLwi3NxShU9J3LYsbc5yWpCX5pn8LmlznqRgEcOws5xzP8w4fU2UMQHryjdhQwr/F/wclXjojQEvxh7IaH+Q2QwFLzrENUVJs5DjRP3Y9F3jTA/g1apAGAM8sfBJ+XayiKqCY0YiGqOqTesQoMCPQi2jmMOIrrkg4VZ20NKBsFrdNwxn5kDBapkE4a8FAG6hqQYnZi2Mqp02i8KmYpQalIJ+CnyL/HE=; 20:XFkBLkT6e17essNMETNW4qEdf8wM0llXeLbtHYGVwWdHvsBrUbpkz5qAAaKxLte2Vk+wZaFel87A6xXESZkBTlRa4zI+2Z0evm+Shd4oQS2c1Awx2Fw14dNqXGLqDnCsEcDolmePUd38esLwuUJ3K1GMH9cy7+gE5NLnmyDx1Pg=
x-ms-office365-filtering-correlation-id: 6a65ee17-765c-470d-8dac-08d412d991b4
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1139;
x-microsoft-antispam-prvs: <AM3PR07MB11396EA159595FD15AAA9623D6B40@AM3PR07MB1139.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(274715658323672)(178726229863574);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040307)(6060326)(6045199)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(6061324); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139;
x-forefront-prvs: 0134AD334F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377454003)(199003)(189002)(52314003)(13464003)(51444003)(24454002)(92566002)(4326007)(2900100001)(561944003)(6512003)(6116002)(93886004)(33656002)(2906002)(86362001)(8936002)(5660300001)(50226002)(42882006)(8676002)(106356001)(3280700002)(3660700001)(81166006)(229853002)(110136003)(81156014)(2950100002)(8666005)(6916009)(5250100002)(102836003)(7846002)(7736002)(305945005)(3846002)(105586002)(106116001)(66066001)(6506003)(101416001)(68736007)(76176999)(74482002)(97736004)(82746002)(189998001)(57306001)(83716003)(50986999)(87936001)(38730400001)(36756003)(7059030)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <93C09DB1A8BB5C4E868E8B847A365C0A@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2016 13:15:02.5793 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139
X-MC-Unique: Qh78zj-1PF-AVEN6A_1Yug-1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/j2Q_PD67VPNow37gtYQoIKNgc5o>
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Nov 2016 13:15:25 -0000

Hi,

> On 22 Nov 2016, at 09:55, t.petch <ietfc@btconnect.com> wrote:
> 
> ----- Original Message -----
> From: "Tim Chown" <Tim.Chown@jisc.ac.uk>
> To: "joel jaeggli" <joelja@bogus.com>
> Cc: <ipv6@ietf.org>
> Sent: Monday, November 21, 2016 10:46 AM
>> 
>>> On 21 Nov 2016, at 09:48, joel jaeggli <joelja@bogus.com> wrote:
>> 
>>>> <snip>
>> 
>>> Registry policies are established at the creation of the registry
>>> 
>>> in the case of
>>> 
>>> IPv6 Neighbor Discovery Option Formats
>>> 
>>> The Registration Procedure is
>>> 
>>> IETF RFC publication
>>> 
>>> for
>>> 
>>> DHCPv6 Option Codes
>>> 
>>> Expert Review and Standards Action
>>> 
>>> Area directors and iana review are expected to hew to requirements
>>> specified in the registries and the doucments which created them.
>>> 
>>> Standards track documents may of course amend the procedures
> associated
>>> with a registry.
>> 
>> So, I guess the question for 6man is whether "Expert Review and
> Standards Action” should also formally be required for new IPv6 Neighbor
> Discovery Option Formats?  Even if it seems to be common practice at the
> moment.  Something to consider when 4861-bis comes up.
> 
> I see 'Expert Review' as something of a political solution to a
> technical problem.  It requires that an expert be found, a backup expert
> when the first is busy, the maintenance of the list of experts over a
> spell of several years when, mostly, the IETF does not have an obvious
> source of expertise (such as a WG).  

Well, the “Expert” is typically a WG. In the case of the capport RA/ND option, a review was requested by an AD on the 6man list. The only thing I think that was missing was a summary of the outcome of the review (it wasn’t posted to the original thread, that I could see). In this case, only one objection was made.

> All of which places a further
> burden on ADs and the IESG, which, naturally, I expect them to resist.

The IESG reviews all I-Ds, but even with many expert eyes, some things can get missed, e.g. the .home issue in homenet.  Some Areas, e.g. Ops and Internet, have a system where the ADs get help from volunteers to provide extra review; a problem there though is not everyone can be “expert" in everything.

> Note too that 'Expert Review' comes just above First-Come First-Served
> in the IANA heirarchy and below anything involving an RFC so the role is
> a relatively weak one, and probably inappropriate for a core protocol.
> And while it is meant to be open, I see it as often being secretive - it
> is there for IANA's benefit, not for that of the IETF.
> 
> If there is a WG, and if the WG is a process rather than project one,
> e.g. TCPM or IDR, then I think that the WG is the better place to go.

I think there are different types of issues that may arise; some may be technical, some may be more architectural, and some may be “religious”. It’s tricky. But I think ensuring there’s a flag waved in (say) 6man for a proposal for a new ND option makes sense; worst case it will delay publication a week or two during the review period, which could always be done in the IETF LC period anyway, I assume.

Tim