Re: [Iasa20] WGLC: draft-ietf-iasa2-rfc4071bis

Nick Doty <npdoty@ischool.berkeley.edu> Mon, 07 January 2019 22:37 UTC

Return-Path: <npdoty@berkeley.edu>
X-Original-To: iasa20@ietfa.amsl.com
Delivered-To: iasa20@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F413112DDA3 for <iasa20@ietfa.amsl.com>; Mon, 7 Jan 2019 14:37:20 -0800 (PST)
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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ischool-berkeley-edu.20150623.gappssmtp.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 lAyT40B7oVJp for <iasa20@ietfa.amsl.com>; Mon, 7 Jan 2019 14:37:18 -0800 (PST)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 44FB112E036 for <iasa20@ietf.org>; Mon, 7 Jan 2019 14:37:18 -0800 (PST)
Received: by mail-pg1-x52a.google.com with SMTP id z11so791801pgu.0 for <iasa20@ietf.org>; Mon, 07 Jan 2019 14:37:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ischool-berkeley-edu.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:cc:to; bh=fy2qCrSBNGJszOnCYrVm7gE/URpGTcaBQLMNGTdwyCs=; b=LYzsJP3XL+9hqW98F4lYiH7dj4KTSxiDeqb4IIa4FM2pQkWECa+jHp3HosD/cX7uOE k5vwqHC3uwhH4++OW7uGa4b6db3Mnh4EgnU5UCJK0y2eSSWCbK6bAqlCRSjUwcSVHHdJ a0JDYU4NlizpXJtjRWJf/SFT7KGULR2cszMEQbT4f/2GGi2T2El3Ls64lZtRacHfER1S y6lgON/9gLzBhAkAk7thV7pTZsmAJR+aQ0brCWP4HUliKNDHRgcvcyd3u/0MsfD3dPy1 JMGKCIcbRjE4HBDgqkwonzBRJdPlBbY5GLcNOnnLsxpO/S/hHdz5YYs2X9FHk8PisNOf 3xFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=fy2qCrSBNGJszOnCYrVm7gE/URpGTcaBQLMNGTdwyCs=; b=DXblB5apCjsiBtsOOGsAo/7IZQOFpYBXi3WjNWC42qh86B5emA+5OZmtlOARjHnqKz uBfrVmxBq/sG37w9XKQHThXoXRBnr4iE8UeJTwQWD0T6zFSQCH+14pOdTng3+7mQPJfE aNswyAcUFzP/GUWfajOFvdh+pPsZTlfa7rdiBcSiND5JApqls7Jh8QUye4slZpTHPxVk 0sUuaDiv6o4Wbhpic8Xj5res0k1MkKIfYFVYT71wHEPe1jBL2ty6vLN37NOxpsQn7OB9 nVpNwBs6n1aCpVPwyJFmMVYGtjWu0LMnttdDJyJnWQxHKMkDNE0yEWNzyTmcJmnxxp0H fcBg==
X-Gm-Message-State: AA+aEWbOUjW/TL5kes1iDCRIWpPHOuXtUwSV226Duc/81cAZqPLuXeCC XngszJBP2UhvzHwmYr7ojigjhMoo4Jc=
X-Google-Smtp-Source: ALg8bN7DOkgfoxZOocp8IDVlVBy53GCarYeWNMs5F6956N3/+HkjxxCIh9cfIVOyaTSVYVAej8nVyw==
X-Received: by 2002:a62:76cc:: with SMTP id r195mr64358567pfc.38.1546900637165; Mon, 07 Jan 2019 14:37:17 -0800 (PST)
Received: from [192.168.0.100] (142-254-99-5.dsl.dynamic.fusionbroadband.com. [142.254.99.5]) by smtp.gmail.com with ESMTPSA id o84sm122415481pfi.172.2019.01.07.14.37.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Jan 2019 14:37:16 -0800 (PST)
From: Nick Doty <npdoty@ischool.berkeley.edu>
Content-Type: multipart/signed; boundary="Apple-Mail=_CDA9E45A-4D89-485E-81BD-B1D32A038E2F"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Message-Id: <E394AA72-4B4F-4C69-9506-C3242B216E62@ischool.berkeley.edu>
Date: Mon, 7 Jan 2019 14:37:22 -0800
Cc: Joseph Lorenzo Hall <joe@cdt.org>
To: iasa20@ietf.org
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/5I4J7ZT5jO9KzSdSVZxIFutYpMU>
Subject: Re: [Iasa20] WGLC: draft-ietf-iasa2-rfc4071bis
X-BeenThere: iasa20@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= <iasa20.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iasa20>, <mailto:iasa20-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iasa20/>
List-Post: <mailto:iasa20@ietf.org>
List-Help: <mailto:iasa20-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iasa20>, <mailto:iasa20-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2019 22:37:21 -0000

Please forgive my non-intimately-involved-with-IETF-administrative-activities eyes if my questions are naive, but perhaps that kind of review will be useful for the WG.

Cheers,
Nick

---

There's a lot of passive voice in these descriptions, which makes it unclear who is making these decisions or executing these actions. For example, from the Introduction:

> Under this structure, the Internet Administrative Oversight Committee (IAOC) is eliminated

Who decided to eliminate the IAOC? When? Is that decision documented? Or:

> Under IASA 2.0, most of the responsibilities that [RFC4071] assigned to the IETF Administrative Director (IAD) and the Internet Society (ISOC) were transferred to the IETF LLC and IETF Administration LLC Executive Director (IETF Executive Director).

Who transferred those responsibilities? Did the IAD and ISOC choose to transfer them, or did they agree with someone else's choice to move them?

I see there are also previous comments on-list regarding the tense of these documents: present, future, past, etc. I agree that consistency there would be helpful in explaining what has happened or will happen. For example, I am genuinely not clear on whether IETF LLC is currently managing IETF's administrative activities or if that's a proposed change for the future. The two examples of passive voice I noted above use different tenses and I'm not sure if that implies something.

RFC4071 describes an effective date as tied to when the document is approved as a BCP, but there is no description of effective date in this document.

> This document outlines how the chosen option is structured

Who chose this option over the other documented options? Was that decision by consensus of IETF or IAOC or some other body?

Section 3.8 "Community Consensus and Grant of Authority" may perhaps be the answer to these questions; if so, that could be clarified. Is the "broad-based community consensus" documented somewhere? Was there an IETF-wide Last Call? Was the broad consensus for the general shift to a disregarded entity, or to all of the details of this IASA 2.0 structure? Is the review of this document intended to be the process of gathering consensus for the IASA 2.0 structure or is that consensus already established and reviews of this document are just reviews of the description of the previous consensus decisions?

I recognize that RFC4071 was equally vague regarding documentation of consensus, but I don’t think that needs to be repeated.

---

>  o  Compliance.  The IETF LLC is responsible for establishing and
> enforcing policies to ensure compliance with applicable laws,
> regulations, and rules.

This bullet point could be interpreted extremely expansively, in ways that may not be desirable. Which jurisdiction's laws will apply to the IETF LLC? If IETF LLC manages the operations of the IETF and a law passes requirements on design of technical systems to enable compliance with court orders providing access to message content, will the LLC be required to establish and enforce policies to ensure compliance with those laws? Ensure compliance by whom?

I think the intent is for the IETF LLC and its staff to follow applicable laws for its own internal operations, rather than the operations or decisions of the IETF, but if so, I think that distinction could be explicitly called out. We should be mindful that the simplicity of having a single independent organization representing the IETF and acting as its fiscal sponsor could also provide simplicity for a government regarding whom to pressure. Naming the administrative entity almost identically to the standard-setting activity could generate real confusion on the separation between the two and the control one exerts over the other.

Later on, the legal compliance areas are described with examples:
> anti-terrorism sanctions, export controls, data protection/privacy

Those seem like areas that might apply to IETF activity as much as or more so than to IETF LLC activity. Would export controls on encryption technology apply to publications of the RFC Editor?