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

[Joseph Lorenzo Hall <[e-mail]>]

Thank you, Nick. Responses inline:

On Mon, Jan 7, 2019 at 5:37 PM Nick Doty <[e-mail]>
wrote:

> 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.
>
>
Very useful, thank you.


> ---
>
> 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.
>
>
(Yes, the IETF Administration LLC is managing IETF's administrative
activities under an interim board structure awaiting nomcom to fill seats
on the first full board.)


> 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.
>
>
(RFC4071 did not have to deal with the external dependencies that we had to
here that I describe below. I suppose the effective date was August 27,
2018 when the ISOC-IETF agreement was executed, but I'm not sure this is
that important?)


> > 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.
>
>
The IASA 2.0 process started in November 2016 with then-IETF Chair Jari
Arkko outlining the need and a potential structure for the IASA 2.0 effort:

https://www.ietf.org/blog/proposed-project-ietf-administrative-support-20/

Subsequently, this involved a number of virtual workshops, establishing
this WG, working with an IASA2 design team to bring potential options to
the WG, and then in 2018 working to put the new structure in place before
ISOC's president left office. This is all to say that this has been long
and complicated, but one of the kinks in the process has been that we had
to tell lawyers what to do before it was even close to reasonable to get
IETF-wide consensus as that takes a very long time. So, the agreement
between ISOC and IETF Administration LLC that establishes the disregarded
entity embeds pieces of this document within it. This document was
previously meant to document the work and decisions made by the IASA2 WG in
arriving at the settled-upon model and ideally would have gone out to
IETF-wide Last Call, etc. closer to the time that the legal agreement was
executed. However, in our collective wisdom, we realized that -struct was
basically a bis of RFC4071 and that we'd need to adapt it to be more of an
rfc4071bis document, which delayed the document until now as those were not
easy edits.

So, we are in essence ratifying the choices made by the IASA2 WG with this
document, but events external to the IETF process had to happen before the
IETF process could complete work on this document. Certainly, getting
rfc4071bis through the IETF process may require changes to the material
that was embedded into the ISOC-IETF legal agreement, and we will have to
go back to the ISOC BoT and get those changes approved to reflect the final
form of this document.

I'm not sure any of this should be inserted directly into the document and
if readers follow the citations to the haberman ID and the IASA workshop
reports, etc. it's certainly possible to construct this from the materials
we cite to.

Nick, I suspect you'll have additional questions and I'd like to hear if
there are ways we can change the document to make sense for people that
have not been as involved in the WG work. I can imagine an "RFC Editor
please remove this before publishing..." section that describes this but
then would let the document stand on its own once published?


> ---
>
> >  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?
>

Yes, we are clear in the document that the IETF Administration LLC exits
only to facilitate the IETF standards process and that nothing in scope of
the IASA2 effort should affect the standards process or the substance of
standards themselves. Practically – and Brad Biddle can weigh in if we need
a more formal answer – the IETF Administration LLC will have to follow US
and Delaware State law. If either of those legal regimes pass laws that
would affect IETF work, the legal agreement has a mechanism for separation
and was designed to be flexible.

I know those of us involved with the legal committee here have spent some
time thinking about things that do touch the IETF standards process, for
example US cryptographic export control laws that require publishers of
encryption source code to report instances of code that performs encryption
to the Department of Commerce (and NSA).

best, Joe

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [e-mail], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871