Subject: Proposed Changes to IAOC Communications Plan; Request for Community Input

From: IETF Administrative Director <[email-masked]>
Date: Wed, 05 Feb 2014 16:47:30 -0800

All;

The IAOC is seeking community feedback on proposed changes to the IAOC 
Communications Plan.

In 2007 the IAOC adopted a Communications Plan in recognition of its responsibility 
under BCP 101 to operate IASA in a transparent manner.  The Plan identifies the 
information to be communicated, the desired frequency and the mode of those communications.  

The Plan can found here:  <http://iaoc.ietf.org/documents/IAOC_Communications_Plan_7-12-07.pdf>.

A markup of the Plan with the proposed changes can be found here: 
<http://iaoc.ietf.org/documents/IAOC-Communications-Plan-2014-Revisions-03.pdf>  The matrix at 
the end of the current plan will be modified to reflect changes adopted by the IAOC following community 
input.

The IAOC is proposing the substantive changes set out below.

The IAOC welcomes your feedback.  All comments received by 17 February will be considered for the 
proposed changes.

Thanks.

Ray
IAD

A.  Proposed Revisions to the Plan
B.  Proposed Additions to the Plan
C.  Proposed Deletions to the Plan

A.  Proposed Revisions to the Plan

	5.2.2 Unaudited Financial Report

	FROM

	The Unaudited Financial Report will provide an
	unaudited review of the financial performance of IASA
	against the previous year’s Budget in March or April of the
	following year. The unaudited report will not be available
	publicly, but will serve to inform the IAOC in anticipation of
	the audited financial report. The report is prepared by the
	Internet Society.

	TO 

	The unaudited Financial Report, prepared by the Internet
	Society, will provide a review of the annual financial
	performance of IASA against budget. This report will be
	available as soon after the end of the calendar year as
	possible, and will be made public. [RFC 4071, §6, 7]

	Reason for Change:  Conformance with ISOC practices.  
	Plus the addition of making the Report public.

5.2.6. Financial Forecast

	FROM

	A financial forecast will be prepared quarterly
	and for ISOC Board of Trustee meetings as required.  [RFC
	4071, §6]

	TO

	5.2.6. Financial Forecast
	Year-End Forecasts shall be prepared by the IAD using the
	financial statements prepared following the first and second
	IETF meetings of the year as advice to the Internet Society,
	and for the IAOC and IAD to manage operations against the
	current annual budget and take appropriate actions. [RFC
	4071, §6]

	Reason for Change: The YEFs are addressed in the IAOC Budget 
	Process & Calendar <http://iaoc.ietf.org/budget-and-finance.html>

B.  Proposed Additions to the Plan

	5.4.1 Subpoenas and Other Legal Requests

	All subpoenas and other legal requests received by the IAOC 
	or the IETF will be published on the IAOC website together
	with their responses. 

	Reason for Change:  Greater transparency.

C.  Proposed Deletions to the Plan

	4.3. IETF Journal
	Periodically the IAOC shall provide reports in the IETF
	Journal. Reports in the Journal shall also be posted on the
	IAOC website.

	Reason for Change: This reporting is redundant with 
	Plenary reports and other online reports on the IAOC site.
	<http://www.internetsociety.org/fr/publications/ietf-journal>

	5.2.3. Audited Financial Report

	The Audited Financial Report will provide an audited review
	of the financial performance of IASA against the Budget.
	The audited report will be available from the Internet
	Society by June of each year. [RFC 4071, §6, 7]

	Reason for Change: IASA is not eligible for a separate audit or audited
	financial statement. IASA financial results are audited as a
	part of Internet Society’s financial audit and therefore
	combined in the consolidated financial statements of
	Internet Society. Therefore, ISOC recommends that section 
	5.2.3 be removed.

	5.3.6. IASA Annual Review
	In March of each year the IAOC shall publish an IASA
	Annual Review reporting on the financial and operational
	health of the organization, as well as its success in meeting its
	goals for the year.

	Reason for Change: Report has not been prepared as it was considered 
	that 3 Plenary reports a year provided the same information.

	5.3.13. Audit Procedures

	The IAOC and ISOC shall agree upon and publish
	procedures for reporting and auditing of the IASA accounts.
	[RFC 4071, §5.1]

	Reason for Change: IASA is not eligible for a separate audit or audited
	financial statement. IASA financial results are audited as a part of Internet 
	Society’s financial audit and therefore 	combined in the consolidated 
	financial statements of 	Internet Society. Therefore, ISOC recommends 
	that section 5.3.13 be removed.

---

From: David Morris <[email-masked]>
Date: Wed, 5 Feb 2014 19:36:46 -0800 (PST)

> 	Reason for Change:  Greater transparency.

Some such requests may include the requirement that they not be revealed.
I don't think it wise to have a published policy which doesn't allow for
such a legal restriction.

---

From: Randy Bush <[email-masked]>
Date: Thu, 06 Feb 2014 12:44:49 +0900

> Some such requests may include the requirement that they not be

they should be rejected out of hand.  "we can not read your email"

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Feb 2014 22:46:39 -0500

> such a legal restriction.

I agree that we need to have a way to conform to a legal requirement.
Are there cases (I imagine that this is one for Jorge) where the mere
fact that a subpoena was received, the matter of which was (legally)
forbidden to publish, is also itself forbidden to publish?  (That is,
do people get subpoenas that not only specify withholding the details,
but prevent the fact of subpoena from being divulged?)  If not,
perhaps the rules could be amended to allow "Cannot publish before
$date due to legal constraint."

If so, boy are we in trouble.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Feb 2014 16:54:15 +1300

> they should be rejected out of hand.  "we can not read your email"

Does that work for National Security Letters too?

---

From: Randy Bush <[email-masked]>
Date: Thu, 06 Feb 2014 12:56:38 +0900

> Does that work for National Security Letters too?

i was thinking of them specifically.  and yes, i have gone to jail for
my political beliefs in the past and would do so again.

randy

---

From: David Morris <[email-masked]>
Date: Wed, 5 Feb 2014 20:49:01 -0800 (PST)

> my political beliefs in the past and would do so again.

As an individual, I laud your willingness to do that, but we can't
ask our administrative staff or volunteer leaders to do that as
a matter of policy. Nor do I think we can afford the legal costs
associated with a court battle.

---

From: Randy Bush <[email-masked]>
Date: Thu, 06 Feb 2014 14:45:02 +0900

maybe we should not focus our policies and procedures on ephemeral fear
based corner case aberrations of one country, which i suspect they will
look back on as they now look back on putting japanese americans in
concentration camps.

randy

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 06 Feb 2014 06:55:12 +0100

> my political beliefs in the past and would do so again.

A "we have problems here" response for me would trigger a request to
review under what jurisdiction IETF operate.

We are a standards body that writes documents.

Not an operator or such that deals with operational issues.

   Patrik

---

From: David Morris <[email-masked]>
Date: Wed, 5 Feb 2014 22:50:30 -0800 (PST)

> Not an operator or such that deals with operational issues.

But we have administrative services, servers, etc. in the United States.
We can argue philosophically about what we are, but if our administrative
support folks or leadership is served with a NSL or FBI warrantless
supoena which stipulates non-disclosure the folks served will have a
hard time with non-compliance. And if our communications Plan stipulates
we always disclose the legal requests, then we have less transparency
than if we have a plan that requires disclosure unless legally prohibited.

If we have the funding or pro-bono legal help to challenge such requests,
then a policy which provides a framework for evaluating which requests
to challenge.

---

From: Chris Elliott <[email-masked]>
Date: Thu, 6 Feb 2014 12:31:45 -0500

> than if we have a plan that requires disclosure unless legally prohibited.

Some companies have announced that they are taking the reverse
approach--reporting on a periodic basis that they have received no requests
that they cannot disclose over the last period. It's obvious what happens
if one or more are received.

Chris.

-- 
Chris Elliott
[email-masked]

---

From: Jorge Contreras <[email-masked]>
Date: Tue, 18 Feb 2014 20:49:24 -0600

All - the IAOC has asked me to respond to this list:

I have taken a look at the proposed Section 5.4.1 and the commentary from
various people:

5.4.1 Subpoenas and Other Legal Requests
   All subpoenas and other legal requests received by the IAOC or the IETF
will be published on the IAOC website together with their responses.

What's important to consider are potential protective orders that may cover
material relating to litigation in which IETF receives a subpoena.  As you
know, and can see from the subpoenas that are already posted on the IETF
web site, some courts (and the ITC) issue protective orders limiting the
use and disclosure of materials produced during discovery.  These orders
typically protect the discloser's confidential information (e.g., if IETF
were asked to disclose confidential information (e.g., salary or credit
card info, or sensitive private communications), it could invoke the terms
of the protective order to ensure that this information would not become
part of the public trial record, and would be seen only by some limited set
of persons (e.g., the judge, legal counsel and perhaps some party
representatives or experts).   To my knowledge, IETF has never been asked
to disclose confidential information, but this could certainly change in
the future.  If that happened, and IETF did disclose this information under
protective order, you would probably not want to disclose it publicly on
the subpoena web page.

The second issue to consider is whether something disclosed TO IETF in the
context of a subpoena or other request may itself by covered by a
protective order.  Again, I'm not aware that this has ever happened, but it
is possible.  For example, if documents were requested from IETF and in
order to understand what was being requested we needed to see some other
(confidential) documents produced during the case, we might receive
material subject to a protective order.  If so, it should clearly not be
posted on the web site.

I think there's a relatively simple fix for these concerns, which is to
tweak Section 5.4.1 by adding the words, ", unless disclosure is prohibited
by law, court order, contract or other legal commitment or would compromise
personal, financial or other sensitive information held by IETF."