[v6ops] accountability vs responsibility [draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?]

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 19 February 2015 19:53 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236471A011E for <v6ops@ietfa.amsl.com>; Thu, 19 Feb 2015 11:53:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 WrUoEGws0PVr for <v6ops@ietfa.amsl.com>; Thu, 19 Feb 2015 11:53:12 -0800 (PST)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C421A877F for <v6ops@ietf.org>; Thu, 19 Feb 2015 11:53:12 -0800 (PST)
Received: by pdev10 with SMTP id v10so2071038pde.7 for <v6ops@ietf.org>; Thu, 19 Feb 2015 11:53:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1BjsnPvFcTYibaPdlBhs+wb+NTlg/K8l+2c2q7edh2M=; b=K8mkGkxl0M8f5z5hjjUPguO27r1AKjQf6w7RcnBz6xugqAwLHeTunGceVZCxlXs4CD MOUBfl/UVdZPSpKbhDg0AyflK41BmmRgROsWpm7xKMtRhY9oMhoGI6WZmrZC3f+d8A14 ITxWoYoUvZO+rt5cxBCfMA/dzRorC8kUAya0XbICMwMWTHbz3bvD0LgqPV582W9mc+1+ hn/yXhELcRM8ThF8onjzivksmSObYRNPidmww3ajy9V35DJEzXLp0CTRbxlC5LbeMSDJ XZDaBVQLoMnBeEMb5UjIIAmQ7tc//ygK6BVZ6SKyJ5FkomNfbdXakyfL0QT2Gi/p4SIk TsEA==
X-Received: by 10.66.148.161 with SMTP id tt1mr10489485pab.85.1424375591244; Thu, 19 Feb 2015 11:53:11 -0800 (PST)
Received: from ?IPv6:2406:e007:652c:1:28cc:dc4c:9703:6781? ([2406:e007:652c:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id c9sm24621799pdj.52.2015.02.19.11.53.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Feb 2015 11:53:10 -0800 (PST)
Message-ID: <54E63F3C.2070404@gmail.com>
Date: Fri, 20 Feb 2015 08:53:32 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "Heatley, Nick" <nick.heatley@ee.co.uk>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Ca By <cb.list6@gmail.com>
References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <CAKD1Yr2PX81czTwUZzaMtgPc9vhvP=oL++UZByGzxmkq_B=DMA@mail.gmail.com> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <CAKD1Yr0Zkic6-ydV-u==xjDGdY9GYWb8KwciBPnfk8zO=6FFqQ@mail.gmail.com> <CAKD1Yr0qS-Vg-XB7mNWwephkkL5rCG+NJO7uDJg_4W3LT+Q9Ew@mail.gmail.com> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <CAKD1Yr00Ri8hQMsJcSqMAw+g_T-mU8GxG1G8rTHgo=McaKdW8Q@mail.gmail.com> <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B93300490D690@OPEXCLILM23.corporate.adroot.infra.ftgroup> <CAD6AjGQ_K2kJCfFbhUxHK4p_5UXAsRpgoeYNtcbg4D+dOq5_4Q@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93300490DAE5@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303E097FB@UK30S005EXS06.EEAD.EEINT.CO.UK>
In-Reply-To: <6536E263028723489CCD5B6821D4B21303E097FB@UK30S005EXS06.EEAD.EEINT.CO.UK>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/OvgeNZgqtMB_72fy1THIiCcgkow>
Cc: "IPv6 Ops WG (v6ops@ietf.org)" <v6ops@ietf.org>
Subject: [v6ops] accountability vs responsibility [draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 19 Feb 2015 19:53:14 -0000

On 19/02/2015 22:14, Heatley, Nick wrote:
> My observation is around accountability vs responsibility (the RACI matrix).
> 
> The issue we seem to have is that the IETF expertise is needed, so we need the IETF community to effectively be the responsible agency for the technical content.
> Normally SDOs are both accountable and responsible.

That isn't clear to me in general.

> Accountability, well, clearly some find it uneasy that IETF would have accountability for the document.

The IETF (and the RFC Editor) is not accountable for anything. Our standards
and recommendations are all voluntary and they all bear a disclaimer (hidden
in the Trust Legal Provisions for recent RFCs) saying something like:
"...DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

The IETF is responsible for the contents in the sense that we require
change control over derivative works of IETF Stream documents.

> If another body could be accountable for the document, that it represents the views of a suitable collective (mobile operators), but the technical content was filtered via IETF, that would be ideal, no?

Not if the IETF fails to reach rough consensus on the contents.

> I have no idea how to engineer such an outcome, but if it could be done then this work should not be wasted – could be a “GSMA sponsored RFC”?

No. If the IETF fails to reach rough consensus, the authors are free to do
whatever they want. If they believe that the "RFC" label has value, they
are free to submit it as an Independent Stream RFC, and the Independent
Submissions Editor then gets to decide whether to publish it:

http://www.rfc-editor.org/indsubs.html

Disclaimer: I am a member of the Independent Submissions editorial board.

   Brian