Subject: [Iasa20] Charter

From: Alissa Cooper <[email-masked]>
Date: Tue, 20 Mar 2018 15:16:19 +0000

The arrangements relating to administrative support for the IETF (referred to
as the "IETF Administrative Support Activity" (IASA) [RFC4071]) were created
more than ten years ago, when the IETF initially took charge of its own
administration.  The arrangements have served the IETF reasonably well, but
there have been considerable changes in the size and scope of the IASA work,
in the world around the IETF, and in the IETF community's own expectations
since the creation of IASA.

As documented in [draft-haberman-iasa20dt-recs-01], the current
administrative arrangements are facing a number of challenges. The range of
IETF administrative tasks have grown considerably; the IASA organizational
structure is not as clear, efficient, or as fully resourced as it should be;
the division of responsibilities between the IETF and ISOC continues to
evolve; expectations about transparency have changed; and the IETF faces
continued challenges related to funding IETF activities against a backdrop of
increasing costs and lack of predictability in our funding streams.

In November 2016, the IETF Chair launched a project in the community to
re-assess the IETF's administrative arrangements. Since then, the IETF
community has discussed the challenges we face, the properties we expect from
future arrangements, options for the legal structure of future arrangements,
and options for the organizational structure of future arrangements.

For legal purposes, IASA is currently
organized as an activity of ISOC. Among multiple legal structure options
considered by the IETF community, the community has elected to create a new
limited liability corporation (LLC) that is a disregarded entity of ISOC
(i.e., it is treated as a branch or division of ISOC for tax purposes) to
house the administration of the IETF. ISOC supports this plan.

This working group is chartered to document the normative changes to IETF
administrative structures and processes necessary to effectuate this change. The main
deliverable will be a document that obsoletes BCP 101. The working group may
produce other supporting documents as necessary to achieve its charter
objective. In parallel, the legal documents necessary to establish the LLC
will be developed outside the working group with the support of legal
counsel. These documents will not be products of the working group, but this
working group will be the venue where these documents will be presented to
the IETF community for review and discussion before they are finalized.

Aside from instances where they presently relate to IASA, it is outside the
scope of this working group to consider any changes to anything related to
the oversight or steering of the standards process as currently conducted by
the IESG and IAB, the appeal chain, the confirming bodies for existing IETF
and IAB appointments, or the IRTF.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 20 Mar 2018 16:05:01 +0000

In principle I'm fine with this charter draft.

However, I want to echo what somehow Elliot already said in the mike.

This is not our "daily" IETF work. This is a key administrative question that every IETF participant needs to be aware of.

They may choose to ignore it, and not participate in this WG, but I think we own the overall IETF and explanation of how we landed in this WG and the proposed charter, why we are excluding already some of the organizational choices, etc.

The risk is a major pushback and comments in another direction of what this "small" group has been drafting until now, but we must do that.

Regards,
Jordi
 
-----Mensaje original-----
De: iasa20 <[email-masked]> en nombre de Alissa Cooper <[email-masked]>
Fecha: martes, 20 de marzo de 2018, 15:16
Para: <[email-masked]>
Asunto: [Iasa20] Charter

    

    
    Aside from instances where they presently relate to IASA, it is outside the
    scope of this working group to consider any changes to anything related to
    the oversight or steering of the standards process as currently conducted by
    the IESG and IAB, the appeal chain, the confirming bodies for existing IETF
    and IAB appointments, or the IRTF.
    _______________________________________________
    iasa20 mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/iasa20

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 20 Mar 2018 16:26:17 +0000

>    They may choose to ignore it, and not participate in this WG, but I think we own the overall IETF and explanation of how we landed in this WG and the proposed charter, why we are excluding alrea…
  
Assuming you meant "owe the overall IETF", I very strongly agree.

Like any other design document, a rationale for explaining why other choices weren't picked can be very very useful.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 20 Mar 2018 12:41:31 -0400

This is something the Design Team can do before we call it a day and
hand over to a potential WG. The first slide I shared did a very rough
summary where you could pull all of this together on your own, but is
there a place (draft-haberman?) that might be best to summarize the
work since Nov 2016/Feb 2017 (IETF Chair announcements about intent to
work on this problem)? 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: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

CDT's Annual Dinner, Tech Prom, is March 29, 2018. Don't miss the tech
event of the year!
Reserve a table today.: https://cdt.org/annual-dinner/

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 20 Mar 2018 16:48:35 +0000

For context for those who were not in attendance at the session at IETF 101: below is a draft charter for a working group to do the IETF document work needed for IASA 2.0. It reflects the hum in the room today in favor of the legal structure choice of LLC.

We can discuss it here; edits can be suggested as PRs at https://github.com/coopdanger/iasa2-charter/blob/master/iasa2-charter.txt <https://github.com/coopdanger/iasa2-charter/blob/master/iasa2-charter.txt> but please also mail the list if you submit a PR.

Thanks,
Alissa

> On Mar 20, 2018, at 3:16 PM, Alissa Cooper <[email-masked]> wrote:
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 20 Mar 2018 19:35:42 +0000

Charter text looks fine to me. Thanks.

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Mar 2018 12:07:56 +1300

Alissa,

> For context for those who were not in attendance at the session at IETF 101: below is a draft charter for a working group to do the IETF document work needed for IASA 2.0. It reflects the hum in th…

Er, I think we need an explicit consensus call here on the list before
wordsmithing a charter. And for that, we'd really need draft minutes.

Also - *definitely* socialise this on [email-masked] ASAP. You do not want
to rerun the whole discussion at Last Call.

   Brian

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 21 Mar 2018 10:40:32 +0000

Hi Brian,

> On Mar 20, 2018, at 11:07 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Alissa,
> 
> wordsmithing a charter.

I sent the charter to the list in a hurry during the session without providing any context, since we were discussing it in the room. So I wanted to provide context for those who were not there. Jon will be sending mail to confirm the hums shortly.

> And for that, we'd really need draft minutes.

Corinne has posted her raw notes.

> to rerun the whole discussion at Last Call.

I will provide context to [email-masked] when the charter goes out for internal review. I think the design team is also planning on capturing the information discussed in the session yesterday in a draft and/or updating their existing draft so supporting documentation will be available during the chartering discussion.

Best,
Alissa

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 21 Mar 2018 06:57:02 -0400

Just want to confirm that I'm updating draft-hall to 1) add context
from the process so far; 2) import the DT requirements from
draft-haberman; 3) walk through the legal options from the ML memo;
and 4) describe the DT's rationale in recommending the disregarded
LLC. I hope to be done in a few days and will send along; we can
decide if that needs to be informational, etc.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Mar 2018 13:00:08 +0000

Alissa Cooper <[email-masked]> wrote:
    > This working group is chartered to document the normative changes to
    > IETF administrative structures and processes necessary to effectuate
    > this change. The main deliverable will be a document that obsoletes BCP
    > 101. The working group may produce other supporting documents as

My understanding of our STD/BCP numbering process is that "BCP 101" will
always be the name for the IETF structure.  But that the underlying RFC that
it points to will get replaced/obsoleted/updated/etc.

Perhaps that's picking at nits... but I think we gotta follow our own
stuff, even if the rest of the world only seens "RFC".

Should it say: updating and replacing the documents that BCP 101 points at,
          such as RFC4071.

Or maybe you intend that we have a new BCP#?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Mar 2018 13:46:35 +0000

> wordsmithing a charter. And for that, we'd really need draft minutes.

The draft minutes I took are on the etherpad:
    https://etherpad.tools.ietf.org/p/notes-ietf-101-iasa20?useMonospaceFont=true

It's not word-for-word, but I hope I captured the essence of the speaker's
points.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 26 Mar 2018 14:48:49 -0400

> On Mar 21, 2018, at 9:00 AM, Michael Richardson <[email-masked]> wrote:
> 
> 

I made a simple change to reflect this: 

s/BCP 101/RFC 4071/
https://github.com/coopdanger/iasa2-charter/commit/727b7af6165078138b83aa093e4597e4dfd39635#diff-990a9bfe64b29e8ba4d3a83a46e58f9d <https://github.com/coopdanger/iasa2-charter/commit/727b7af6165078138b83aa093e4597e4dfd39635#diff-990a9bfe64b29e8ba4d3a83a46e58f9d>

This still lets the WG update other docs as well.

Thanks,
Alissa

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Mar 2018 08:23:19 +1300

> This still lets the WG update other docs as well.

The change is fine. 

In fact RFC 4371 will need to be updated at the same time as the Trust Agreement,
since both depend on the existence of the IAOC. There's no need for that to be
done by the WG itself, but it needs to be synchronized.

Also, RFC 7691 makes no sense without RFC 4071, so that will also
have to be obsoleted.

   Brian

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 28 Mar 2018 08:07:06 -0700

> On Mar 26, 2018, at 12:23 PM, Brian E Carpenter <[email-masked]> wrote:
> 
>> https://github.com/coopdanger/iasa2-charter/commit/727b7af6165078138b83aa093e4597e4dfd39635#diff-990a9bfe64b29e8ba4d3a83a46e58f9d <https://github.com/coopdanger/iasa2-charter/commit/727b7af6165078138b83aa093e4597e4dfd39635#diff-990a9bfe64b29e8ba4d3a83a46e58f9d><https://github.com/coopdanger/iasa2-charter/commit/727b7af6165078138b83aa093e4597e4dfd39635#diff-990a9bfe64b29e8ba4d3a83a46e58f9d <https://github.com/coopdanger/iasa2-charter/commit/727b7af6165078138b83aa093e4597e4dfd39635#diff-990a9bfe64b29e8ba4d3a83a46e58f9d>>
>> 

Thanks. I made a few small changes, including one to make sure it’s clear that other documents will be updated or obsoleted: <https://github.com/coopdanger/iasa2-charter/commit/d7f987a92dd2323167322f85aeec4b65d536bb17#diff-990a9bfe64b29e8ba4d3a83a46e58f9d <https://github.com/coopdanger/iasa2-charter/commit/d7f987a92dd2323167322f85aeec4b65d536bb17#diff-990a9bfe64b29e8ba4d3a83a46e58f9d>>. I also added milestones and clarified the selection of the LLC since it seemed to be a bit confusing in an off-list exchange I’ve had.

I loaded this version into the datatracker: <https://datatracker.ietf.org/doc/charter-ietf-iasa2/ <https://datatracker.ietf.org/doc/charter-ietf-iasa2/>>.  It’s now in internal review by the IESG and IAB and I’ve added it to the April 5 IESG telechat for approval to go out for community review. But changes can still be made between now and then.

Alissa