Subject: [Iasa20] Comments on <draft-ietf-iasa2-rfc4071bis-00>

From: Bob Hinden <[email-masked]>
Date: Thu, 13 Dec 2018 16:34:24 -0800

Hi,

My comments below.  They range from editorial to substantive.

Note, to make this shorter, I removed text I wasn’t commenting on.

Thanks,
Bob

> 
> 
> 
> 
> IASA2                                                        B. Haberman
> Internet-Draft                                  Johns Hopkins University
> Obsoletes: RFC4071, RFC4333, RFC7691 (if                         J. Hall
>            approved)                                                 CDT
> Intended status: Best Current Practice                      J. Livingood
> Expires: June 8, 2019                                            Comcast
>                                                        December 05, 2018
> 
> 
>    Structure of the IETF Administrative Support Activity, Version 2.0
>                      draft-ietf-iasa2-rfc4071bis-00
> 
> 

. . . .

> 1.  Introduction
> 
>    The IETF Administrative Support Activity (IASA) was originally
>    established in 2005.  In the years since then, the needs of the IETF
>    evolved in ways that required changes to its administrative
>    structure.  The purpose of this document is to document and describe
>    the IASA 2.0 structure.
> 
>    Under IASA 2.0, the work of the IETF's administrative and fundraising
>    tasks is conducted by an administrative organization, the IETF
>    Administration Limited Liability Company ("IETF LLC").  Under this
>    structure, the Internet Administrative Oversight Committee (IAOC) was

s/was/is/

To my thinking this hasn't happend until this document is approved.   For
example, until RFC4333 is obsoleted when this document is approved.  It's
not past tense yet.

>    eliminated, and its oversight and advising functions transferred to
>    the IETF LLC Board.
> 
>    [I-D.haberman-iasa20dt-recs] discusses the challenges facing the
>    original IASA structure as well as several options for reorganizing
>    the IETF's administration under different legal structures.  This
>    document outlines how the chosen option is structured and describes
> 
> 
> 
> 
> Haberman, et al.          Expires June 8, 2019                  [Page 3]
> Internet-Draft                    IASA2                    December 2018
> 
> 
>    how the organization fits together with existing and new IETF
>    community structures.
> 
>    The point of the IASA2 WG and process has been to solicit community
>    input about how to address the challenges identified in
>    [I-D.haberman-iasa20dt-recs], and included much debate on the IASA2
>    mailing list and the IASA2 working group meetings at IETF 101
>    [ietf101-slides] and IETF 102 [ietf102-slides].
> 
>    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).  It is the job of the
>    IETF LLC to meet the administrative needs of the IETF and to ensure
>    that the IETF LLC meets the needs of the IETF community.
> 
>    Eliminating the IAOC meant that changes were required in how trustees
>    could be appointed to the IETF Trust.  The details of how this is
>    done are outside the scope of this document but are covered in
>    [I-D.ietf-iasa2-trust-update].
> 
>    This document obsoletes [RFC4071], which specified the original IASA,
>    [RFC4333], which specified the selection guidelines and process for
>    IAOC members and [RFC7691], which specified terms for IAOC members.

Does this doucment also update BCP101?   I think so, if it does, it should be
mentioned here.

> 2.  Scope Limitation
> 
>    The document does not propose any changes to anything related to the

s/propose/make/

When approved, it's not a proposal.

>    oversight or steering of the standards process as currently conducted
>    by the Internet Engineering Steering Group (IESG) and Internet
>    Architecture Board (IAB), the appeals chain, the process for making
>    and confirming IETF and IAB appointments, the IETF Nominating
>    Committee (NomCom), the Internet Research Task Force (IRTF), or
>    ISOC's memberships in or support of other organizations.

I note the NomCom responsibilities are changing, they will now appoint some
IETF LLC Board members and IETF Trust Trustees.  This text isn't quite
right.

> 2.1.  LLC Agreement with the Internet Society
> 
>    The LLC Agreement between the IETF LLC and ISOC [IETF-LLC-A] is also
>    out of scope for this document, however this document depends on the
>    LLC Agreement and will refer to it for certain aspects of the legal
>    relationship between the IETF LLC and ISOC.  The LLC Agreement was
>    developed between legal representatives of the IETF and ISOC and
>    includes all critical terms of the relationship, while still enabling
>    maximum unilateral flexibility for the IETF LLC Board.  The LLC
>    Agreement includes only basic details about how the IETF LLC Board
>    manages itself or manages IETF LLC staff, so that the IETF LLC Board
>    has flexibility to make changes without amending the agreement.  The
> 
> 
> 
> 
> Haberman, et al.          Expires June 8, 2019                  [Page 4]
> Internet-Draft                    IASA2                    December 2018
> 
> 
>    IETF LLC Board can independently develop policy or procedures
>    documents that fill gaps.
> 
> 3.  Definitions and Principles
> 
> 3.1.  Alphabet Soup

Just call this “terminology"?   Do we need to be cute here?

>    Although most of the terms, abbreviations, and acronyms used in this
>    document are reasonably well known, first-time readers may find this
>    alphabet soup confusing.  This section therefore attempts to provide
>    a quick summary.

Please rewrite this.   Some of these are well known (IESG, IAB, etc.), but
the rest (IETF LLC) are not.

>    IAB: Internet Architecture Board (see [RFC2026], [RFC2850]).
> 
>    IAD: IETF Administrative Director, a role obsoleted by this document
>    and the ISOC/IETF LLC Agreement ([IETF-LLC-A]) and replaced by the
>    IETF LLC Executive Director.
> 
>    IAOC: IETF Administrative Oversight Committee, a committee that
>    oversaw IETF administrative activity, obsoleted by this document and
>    replaced by the IETF LLC Board.  (The IETF Trust function of the
>    former IAOC was not included in the new responsibilities of the IETF
>    LLC Board (See [I-D.ietf-iasa2-trust-update]).)
> 
>    IASA: The original IETF Administrative Support Activity, defined by
>    [RFC4071] and obsoleted by this document and the ISOC/IETF LLC
>    Agreement ([IETF-LLC-A]).

I disagree.  IASA is the general term that applies to IASA 1.0 and IASA
2.0.  Perhaps in the future IASA 3.0.

>    IASA 2.0: Version 2.0 of the IETF Administrative Support Activity,
>    defined by this document.
> 
>    IESG: Internet Engineering Steering Group (see [RFC2026], [RFC3710]).
> 
>    IETF: Internet Engineering Task Force (see [RFC3233]).
> 
>    IETF Administration LLC: The legal entity - a disregarded Limited
>    Liability Company (LLC) of The Internet Society - established to
>    house IASA2, specified by the ISOC/IETF LLC Agreement ([IETF-LLC-A]).
>    Also referred to as "IETF LLC" or just the "LLC".

Please, only give it one name, like IETF LLC.   Having multiple names
for the same thing will be confusing.

>    IETF LLC Executive Director: the executive director for the IETF
>    Administration Limited Liability Company, responsible for day-to-day
>    administrative and operational direction (See Section 4.1).  Also
>    referred to as "IETF Executive Director".  (Note that the title of
>    "IETF Executive Director" in older documents such as [RFC2026] is now
>    "Managing Director, IETF Secretariat".)

I thought the name was going to be "IETF Executive Director".  I am fine
with now calling it the "IETF LLC Executive Director", but it should only
have one name.   Either is fine in my view, but not both.

> Haberman, et al.          Expires June 8, 2019                  [Page 5]
> Internet-Draft                    IASA2                    December 2018
> 
> 
>    IETF LLC Board: The Board of Directors of the IETF LLC - formally a
>    multi-member "manager" of the IETF LLC on behalf of ISOC (See
>    Section 4.2).
> 
>    ISOC: Internet Society (see [RFC2031] and [ISOC]).
> 
> 3.2.  Key Differences From the Old IASA Structure to IASA 2.0
> 
>    o  The IAOC and IAD roles defined in RFC 4071 were eliminated.

s/were/are/

Please change this from past tense elsewhere too.

> 
>    o  The former ISOC and IAD responsibilities were assigned to a new
>       organization, IETF Administration LLC.
> 

s/were/are/

>    o  The Board of Directors of the IETF LLC - formally a multi-member
>       "manager" of the IETF LLC on behalf of ISOC - assumed the
>       oversight responsibilities of the IAOC.

Does [formally a multi-member "manager" of the IETF LLC on behalf of ISOC] need to be here?  Formal part was defined earlier.

> 
>    o  The Board of the IETF LLC is more focused on strategy and
>       oversight than the IAOC was, with the IETF Executive Director and
>       their team in charge of day-to-day operations.
> 
>    o  The IAD role was replaced with the IETF Executive Director role.

s/was/is/

> 
>    o  The role that was previously referred to as "IETF Executive
>       Director" in older documents such as [RFC2026] was replaced with
>       "Managing Director, IETF Secretariat”.

s/was/is/

> 
> 3.3.  General IETF LLC Responsibilities
> 
>    The IETF LLC was established to provide administrative support to the
>    IETF.  It has no authority over the standards development activities
>    of the IETF.

s/was/is/

> 
>    The responsibilities of the IETF LLC are:
> 
>    o  Operations.  The IETF LLC is responsible for supporting the
>       ongoing operations of the IETF, including meetings and non-meeting
>       activities.
> 
> 

. . . .

> 3.4.  IETF LLC Working Principles
> 
>    The IETF LLC is expected to conduct its work according to the
>    following principles, subject to any reasonable confidentiality
>    obligations:
> 
>    o  Transparency.  The IETF LLC is expected to keep the IETF community
>       informed about its work and to engage with the community to obtain
>       consensus-based community input on key issues and otherwise as
>       needed.  The IETF community expects complete visibility into the
>       financial and legal structure of the IETF LLC.  This includes
>       information about the IETF LLC annual budget and associated
>       regular financial reports, results of financial and any other
>       independent audits, tax filings, significant contracts or other
>       significant long-term financial commitments that bind the IETF
>       LLC.  As discussed in [ietf101-slides], whatever doesn't have a
>       specific justification for being kept confidential is expected to
>       be made public.  The IETF LLC Board is expected to develop and
>       maintain a public list of confidential items, describing the
>       nature of the information and the reason for confidentiality.
> 
>    o  Responsiveness to the community.  The IETF LLC is expected to act
>       consistently with the documented consensus of the IETF community,
>       to be responsive to the community's needs, and to adapt its
>       decisions in response to consensus-based community feedback.
> 
>    o  Diligence.  The IETF LLC is expected to act responsibly so as to
>       minimize risks to IETF participants and to the future of the IETF
>       as a whole, such as financial risks.
> 
>    o  Unification: The IETF LLC is reponsible for providing unified
>       legal, financial, and administrative support for operation of the
>       IETF, IAB, IESG, IRTF, and RFC Editor.
> 

I think it is correct that the IETF Trust is not included here.  Might be good to call that out.  That said, where does the IETF Trust get it’s funding?

>  Haberman, et al.          Expires June 8, 2019                  [Page 7]
> Internet-Draft                    IASA2                    December 2018
> 
> 
>    o  Transfer or Dissolution: Consistent with [IETF-LLC-A], the IETF
>       LLC subsidiary may be transferred from ISOC to another
>       organization, at the request of either party.  Similarly, the IETF
>       LLC may be dissolved if necessary.  Should either event occur, the
>       IETF community should be closely involved in any decisions and
>       plans, and any tranfer, transition, or dissolution conducted
>       carefully and with minimal potential disruption to the IETF.
> 
>    The transparency and responsiveness principles are designed to
>    address the concern outlined in Section 3.3 of
>    [I-D.haberman-iasa20dt-recs] about the need for improved timeliness
>    of sharing of information and decisions and seeking community
>    comments.  The issue of increased transparency was important
>    throughout the IASA 2.0 process, with little to no dissent.  It was
>    recognized that there will naturally be a confidentiality requirement
>    about some aspects of hotel contracting, personnel matters, and other
>    narrow areas.

. .  . .

> 
> 
> 3.7.  IETF LLC Board Decision Making
> 
>    The IETF LLC Board attempts to reach consensus on all decisions.  If
>    the IETF LLC Board cannot achieve a consensus decision, then the IETF
>    LLC Board may decide by voting.

I would hope that most board decision should be unanimous.  Is that what “concensus” is intended to mean?

I think it would be good that all major decisions are voted on and the results are recorded.  This should include budgets, hiring/firing, major contracts, selection of IETF meeting venues, etc.

> 
>    The IETF LLC Board decides the details about its decision-making
>    rules, including its rules for quorum (see Section 5.9), conflict of
>    interest (see Section 7.1), and breaking of ties.  These rules are
>    expected to be public.
> 
>    All IETF LLC Board decisions are expected to be recorded in IETF LLC
>    Board minutes, and IETF LLC Board minutes are expected to be
>    published in a timely fashion.
> 
> 3.8.  Review and Appeal of IETF Executive Director and IETF LLC Board
>       Decisions
> 
>    The IETF LLC Board is directly accountable to the IETF community for
>    the performance of the IASA 2.0.  In order to achieve this, the IETF
>    LLC Board and IETF Executive Director are expected to ensure that
>    guidelines are developed for regular operational decision making.
>    Where appropriate, these guidelines should be developed with public
>    input.  In all cases, they must be made public.

Why is the IETF Executive Director called out here?   Is there a distinction?  Please explain?

. . . . .

> Haberman, et al.          Expires June 8, 2019                  [Page 9]
> Internet-Draft                    IASA2                    December 2018
> 
> 
>    If a member of the community is not satisfied with the IETF LLC
>    Board's response to his or her review request, he or she may escalate
>    the issue by appealing the decision or action to the IAB, using the
>    appeals procedures outlined in [RFC2026].  If he or she is not
>    satisfied with the IAB response, he or she can escalate the issue to
>    the ISOC Board of Trustees, as described in [RFC2026].
> 
>    The reviewing body (the IAB or ISOC Board of Trustees) shall review
>    the decision of the IETF Executive Director or IETF LLC Board to
>    determine whether it was made in accordance with existing BCPs and
>    operational guidelines.  As a result of this review, the reviewing
>    body may recommend to the community that the BCPs governing IETF LLC
>    Board actions should be changed.  The reviewing body may also advise
>    the IETF LLC Board to modify existing operational guidelines to avoid
>    similar issues in the future and/or it may advise the IETF LLC Board
>    to re-consider their decision or action.  It may also recommend that
>    no action be taken, based on the review.
> 
>    In exceptional cases, when no other recourse seems reasonable, the
>    reviewing body may overturn or reverse a non-binding decision or
>    action of the IETF LLC Board.  This should be done only after careful
>    consideration and consultation with the IETF LLC Board regarding the
>    ramifications of this action.  In no circumstances may the IAB or
>    ISOC Board of Trustees overturn a decision of the IETF LLC Board that
>    involves a binding contract or overturn a personnel-related action
>    (such as hiring, firing, promotion, demotion, performance reviews,
>    salary adjustments, etc.).

Is this actually legal and consistent with [IETF-LLC-A] and the State of Delaware laws regarding LLCs?  I suspect it isn’t.

> 
> 3.9.  Community Consensus and Grant of Authority
> 
>    The IETF is a consensus-based group, and authority to act on behalf
>    of the community requires a high degree of consensus and the
>    continued consent of the community.  After a careful process of
>    deliberation, a broad-based community consensus emerged to house the
>    administration of the IETF within the IETF LLC as a disregarded
>    entity of the Internet Society.  This document reflects that
>    consensus.

Sorry, when was the IETF Last call to determine "a broad-based community consensus"?

The degree of consensus will be determined when this document is approved via our normal processes (IETF Last Call, IESG review and decision).  This text implies it has already happened.

Please revise.

. . . .

> 4.2.  IETF LLC Board Responsibilities
> 
>    The IETF LLC Board is responsible for conducting oversight of the
>    IETF LLC's execution of its responsibilities, as described in
>    Section 3.3.  They have duties of loyalty, care, and good faith.
>    This includes the responsibility to:
> 
>    o  provide strategic direction for the IETF LLC to the IETF Executive
>       Director;
> 
>    o  hire, supervise, and manage the employment of the role of the IETF
>       Executive Director of the IETF LLC, including tasks such as
>       hiring, termination, performance review, amendment of employment
>       terms, the award of compensation and other requisite employment
>       benefits or decisions;
> 

Does the LLC Board or Executive director do these talks for staff hired by the Executive Director.  It should be specified.

. . . . .

> 
> 
> Haberman, et al.          Expires June 8, 2019                 [Page 13]
> Internet-Draft                    IASA2                    December 2018
> 
> 
>    o  Provides assistance to help facilitate ISOC's tax compliance,
>       including but not limited to assistance related to preparing the
>       Form 990 and responding to any IRS questions and audits;
> 
>    o  Obtains appropriate insurance, including commercial general
>       liability insurance with appropriate limits;

Who will the liability insurance cover?   I believe that we currently have liability insurance down through w.g. chairs.  Will this continue?

> 
>    o  Implements risk management and compliance processes in a manner
>       consistent with industry norms.
> 
>    The description below outlines the composition of the IETF LLC Board,
>    selection of IETF LLC Board Directors, and related details.
> 
> 

. . . . .

> Haberman, et al.          Expires June 8, 2019                 [Page 14]
> Internet-Draft                    IASA2                    December 2018
> 
> 
>    o  1 Appointed by the ISOC Board of Trustees
> 
>    o  3 Selected by the IETF NomCom, confirmed by the IESG
> 
>    o  Up to 2 Appointed by the IETF LLC board itself, on an as-needed
>       basis, confirmed by the IESG
> 
>    For the first slot listed above, the presumption is that the IETF
>    Chair will serve on the board.  At the IESG's discretion, another
>    area director may serve instead, or exceptionally the IESG may run a
>    selection process to appoint a director.  The goal of having this
>    slot on the board is to maintain coordination and communication
>    between the board and the IESG.

I think it would be good if there was stronger text to encourage the IETF Chair to serve on the board.  Everything will work better if there is closer alignment.

> 
> 5.2.  IETF LLC-Appointed Directors

s/IETF LLC-Appointed Directors/IETF LLC Appointed Directors/

remove the “-“

. . . . .

> 
> 5.5.  IETF LLC Board Director Limit
> 
>    A director may serve no more than two consecutive terms, with at
>    least one full term prior to the start of any additional terms.  An

I am having trouble parsing this, the part that starts with “at least one…”   Please rewrite to clarify.  I think it means that a person can not serve a third term unless three years has passed, but can’t tell for sure.

>    exception is if a Director role is occupied by the IETF Chair ex
>    officio, since that person's service is governed instead by the term
>    lengths established in [RFC7437] (BCP10), Section 3.4.
> 
>    An exception to the two consecutive term rule is for an IETF LLC-
>    appointed Director.  For such a Director, they may serve only one
>    term via this appointment method, after which any subsequent terms
>    would be occur via other appointment or selection processes (such as
>    via the NomCom process).
> 
>    Lastly, partial terms of less than three years for the initial
>    appointments to the first full board, for which some Directors will
>    have terms of one or two years, do not count against the term limit.
> 
>    The limit on consecutive terms supports the healthy regular
>    introduction of new ideas and energy into the Board and mitigates
>    potential long-term risk of ossification or conflict, without
>    adversely impacting the potential pool of director candidates over
>    time.
> 
> 5.6.  Staggered Terms
> 
>    ISOC, the IESG, the Nominating Committee, and the Board are expected

s/ISOC/ISOC Board of Trustees/

>    to coordinate with each other to ensure that collectively their
>    appointment or selection processes provide for no more than three
>    Directors' terms concluding in the same year.
> 
> 5.7.  IETF LLC Board Director Removal
> 
>    Directors may be removed with or without cause.  A vote in favor of
>    removal must be no fewer than the number of Directors less two.  So
>    for example, if there are seven directors, then five votes are
>    required.  Directors may also be removed via the IETF recall process
>    defined in [RFC7437] (BCP10), Section 7.

This should point to RFC7437bis.   RFC7437 doesn’t include the IETF LLC.

> 
> 
> 
> 
> Haberman, et al.          Expires June 8, 2019                 [Page 16]
> Internet-Draft                    IASA2                    December 2018
> 
> 
> 5.8.  Filling an IETF LLC Board Director Vacancy
> 
>    It shall be the responsibility of each respective body that appointed
>    or selected a Director that vacates the Board to appoint a new
>    Director to fill the vacancy.  For example, if a Director selected by
>    the NomCom departs the Board prior to the end of their term for
>    whatever reason, then it is the responsibility of the NomCom (using
>    its mid-term rules, as specified in [RFC8318], Section 3.5) as the
>    original appointing body to designate a replacement that will serve
>    out the remainder of the term of the departed Director.  However,
>    this obligation will not apply to vacancies in Board-appointed
>    positions.
> 
> 5.9.  Quorum
> 
>    At all meetings of the Board, at least 2/3 of the Directors then in
>    office constitute a quorum for the transaction of business.  If a
>    quorum is not be present at any meeting of the Board, the Directors
>    present thereat may adjourn the meeting without notice other than

I think “present thereat” is redundant.   Suggest one or the other.

>    announcement at the meeting, until a quorum is present.
> 
> 5.10.  Board Voting
> 
>    The Board can hold votes during synchronous live meetings of the

I think "synchronous live” is also redundant.

>    Board (including telephonic and video) or via asynchronous written
>    (including electronic) means.  A given vote shall be either conducted
>    entirely during a synchronous live meeting or entirely via
>    asynchronous written means, not a mix of the two.  Decisions on
>    regular IETF LLC matters require a 2/3 majority vote in favor, with
>    the exception of removal of a Director as specified in Section 5.7.
>    Absentee voting and voting by proxy are not permitted.

This whole paragraph could be written to be clearer.  I think it is trying to say a vote can be held by people attending a meeting or by email, but not a mix of the two.

. . . . .

> 6.1.  Financial Statements
> 
>    As noted in Section 4.2, the IETF LLC must comply with relevant tax
>    laws, such as filing an annual IRS Form 990.  Other official

I strongly suspect that an annual tax return is also required in addition to the 990.

>    financial statements may also be required.
> 
>    In addition to these official financial statements and forms, the
>    IETF LLC is also expected to report on a regular basis to the IETF
>    community on the current and future annual budget, budget forecasts
>    vs. actuals over the course of a fiscal year, and on other
>    significant projects as needed.  This regular reporting to the IETF
>    community is expected to be reported in the form of standard
>    financial statements that reflect the income, expenses, assets, and
>    liabilities of the IETF LLC.
> 

Will the tax reports be made available publicly?  I think they should be, but I don’t see it here.

> 
> 
> Haberman, et al.          Expires June 8, 2019                 [Page 18]
> Internet-Draft                    IASA2                    December 2018
> 
> 
> 6.2.  Bank and Investment Accounts
> 
>    The IETF LLC maintains its own bank account, separate and distinct
>    from ISOC.  The IETF LLC may at its discretion create additional
>    accounts as needed.  Similarly, the IETF LLC may as needed create
>    investment accounts in support of its financial goals and objectives.
> 
> 6.3.  Financial Audits
> 
>    The IETF LLC is expected to retain and work with an independent
>    auditor.  Reports from the auditor are expected to be shared with the
>    IETF community and other groups and organizations as needed or as
>    required by law.
> 
> 6.4.  ISOC Financial Support
> 
>    ISOC currently provides significant financial support to the IETF
>    LLC.  Exhibit B of the [IETF-LLC-A] summarizes the one-time and on-
>    going financial support from ISOC for the forseeable future.  It is
>    envisioned that this support will be periodically reviewed and
>    revised, via a cooperative assessment process between ISOC and the
>    IETF LLC.
> 

Suggest a stronger word than “envisioned”.  Saying that it is important is an understatement.

> 6.5.  IETF Meeting Revenues
> 
>    Meeting revenues are another important source of funding that
>    supports the IETF, comining mainly from the fees paid by IETF meeting
>    participants.  The IETF Executive Director sets those meeting fees,
>    in consultation with the IETF LLC and the IETF community, with formal
>    approval by the IETF LLC.  Setting these fees and projecting the
>    number of participants at future meetings is a key part of the annual
>    budget process.
> 
> 6.6.  Donations to the IETF LLC
> 
>    Donations are an essential component of the financial support for the
>    IETF.  Within the general bounds noted in Section 6.8, the IETF LLC
>    is responsible for fundraising activities in order to establish,
>    maintain, and grow a strong foundation of donation revenues.  This
>    can and does include both direct financial contributions as well as
>    in-kind contributions, such as equipment, software licenses, and
>    services.
> 
>    Donations to the IETF LLC shall not convey to donors any special

Suggest /shall/must/

>    oversight or direct influence over the IETF's technical work or other
>    activities of the IETF or IETF LLC.  This helps ensure that no undue
>    influence may be ascribed to those from whom funds are raised, and so
>    helps to maintain an open and consensus-based IETF standards process.
> 
> 
> 
> Haberman, et al.          Expires June 8, 2019                 [Page 19]
> Internet-Draft                    IASA2                    December 2018
> 
> 
>    To the extent that the IETF LLC needs to undertake any significant
>    special projects for the IETF, the IETF LLC may need to fundraise
>    distinctly for those special projects.  As a result, the IETF LLC may
>    conduct fundraising to support the IETF in general as well as one or
>    more special fundraising efforts (which may also be accounted for
>    distinctly and be held in a separate bank account or investment, as
>    needed).
> 
> 6.7.  Funding Supports the IETF
> 
>    The IETF LLC exists to support the IETF.  Therefore, the IETF LLC's
>    funding and all revenues, in-kind contributions, and other income
>    that comprise that funding shall be used solely to support IETF-
>    related activities and for no other purposes.

Good!

> 
> 6.8.  Charitable Fundraising Practices
> 
>    When the IETF LLC conducts fundraising, it substantiates charitable
>    contributions on behalf of ISOC.

I don’t understand what "substantiates charitable contributions on behalf of ISOC” means.  Please explain.

> The IETF LLC evaluates and
>    facilitates state, federal, and other applicable law and regulatory
>    compliance for ISOC and/or the LLC with respect to such fundraising
>    activities.  In addition, the IETF LLC ensures that all fundraising
>    activities are conducted in compliance with any policies developed by
>    the IETF LLC, including but not limited to those noted in Section 7.
> 
> 

. . . . .

> 
> 
> Haberman, et al.          Expires June 8, 2019                 [Page 20]
> Internet-Draft                    IASA2                    December 2018
> 
> 
>    IETF LLC meeting applicable legal and tax requirements and is a core
>    part of the IETF LLC Board's fiduciary responsibilities.
> 
>    As explained in Section 4.1, the IETF Executive Director is expected
>    to develop, execute, and report on the annual budget.  Regular
>    reporting is expected to include monthly and quarterly forecast vs.
>    budget statements, including updated projections of income and
>    expenses for the full fiscal year.
> 
>    The IETF LLC Board, as explained in Section 4.2, is expected to
>    review and approve the budget, as well as to provide ongoing
>    oversight of the budget and of any other significant financial
>    matters.
> 
>    The annual budget is expected to be developed in an open,
>    transparent, and collaborative manner, in accordance with
>    Section 3.4.  The specific timeline for the development, review, and
>    approval of the IETF LLC annual budget is established by the IETF LLC
>    Board and may be revised as needed.

I suggest adding something about also developing a longer term running budget (~ 5 years).   Only an annual budget is not enough.

I don’t see anything about debt.  Can the IETF LLC go into debt?   Can it borrow money?  Or does it just ask ISOC for more money?

> 
> 7.  IETF LLC Policies
> 
>    The Board is expected to maintain policies as necessary to achieve
>    the goals of the IETF LLC, meet transparency expectations of the
>    community, comply with applicable laws or regulations, or for other
>    reasons as appropriate.  All policies are expected to be developed
>    with input from the IETF community.  Some policies provided by ISOC
>    may provide a useful starting point for the Board to consider.

Suggest adding IAOC developed policies as well.  They were developed over the time the IAOC was running and take into account working with the IETF community.  We should learn from that experience.

> 
> 7.1.  Conflict of Interest Policy
> 
>    The Board is expected to maintain a Conflict of Interest policy for
>    the IETF LLC.  While the details are determined by the Board, at a
>    minimum such policy is expected to include the following:
> 
>    o  The IETF, ISOC Board, IAB, or IRTF chair cannot be chair of this
>       IETF LLC Board, though they may serve as a Director.
> 
>    o  A Director cannot be a paid consultant or employee of the IETF
>       Executive Director or their sub-contractors, nor a paid consultant
>       or employee of ISOC.

Should the affiliation of LLC directors be transparent?   If they are a consultant, should we know who their major source of income is from?

. . . . .

> 7.3.  Compliance
> 
>    The IETF LLC is expected to implement a compliance program to ensure
>    its compliance with all applicable laws, rules and regulations,
>    including without limitation laws governing bribery, anti-terrorism
>    sanctions, export controls, data protection/privacy, as well as other
>    applicable policies noted in Section 7.  In addition, actions and
>    activities of the IETF LLC must be consistent with 501(c)(3)
>    purposes.
> 
>    The IETF LLC is expected report to ISOC on the implementation of its
>    compliance plan on an annual basis.

Please add “and the IETF community”

> 
> 8.  Three-Year Assessment
> 
>    The IETF LLC, with the involvement of the community, shall conduct
>    and complete an assessment of the structure, processes, and operation
>    of IASA 2.0 and the IETF LLC.  This should be presented to the
>    community after a period of roughly three years of operation.  The
>    assessment may potentially include recommendations for improvements
>    or changes to the IASA2 and/or IETF LLC.

Might be good for a first year report, then every three years.

> 
> 
> 
> Haberman, et al.          Expires June 8, 2019                 [Page 22]
> Internet-Draft                    IASA2                    December 2018
> 
> 
> 9.  Security Considerations
> 
>    This document describes the structure of the IETF's Administrative
>    Aupport Activity (IASA), version 2 (IASA2).  It introduces no
>    security considerations for the Internet.

I hope so :-)

> 
> 10.  IANA Considerations
> 
>    This document has no IANA considerations in the traditional sense.
>    However, some of the information in this document may affect how the
>    IETF standards process interfaces with the IANA, so the IANA may be
>    interested in the contents.
> 
> 11.  Acknowledgments
> 
>    Thanks to Jari Arkko, Richard Barnes, Brian E Carpenter, Alissa
>    Cooper, John C Klensin, Bob Hinden, Jon Peterson, Sean Turner and the
>    IASA2 Working Group for discussions of possible structures, and to
>    the attorneys of Morgan Lewis and Brad Biddle for legal advice.
> 
> 12.  Informative References
> 
>    [I-D.haberman-iasa20dt-recs]
>               Haberman, B., Arkko, J., Daigle, L., Livingood, J., Hall,
>               J., and E. Rescorla, "IASA 2.0 Design Team
>               Recommendations", draft-haberman-iasa20dt-recs-03 (work in
>               progress), November 2018.
> 
>    [I-D.ietf-iasa2-rfc2031bis]
>               Camarillo, G. and J. Livingood, "The Updated IETF-ISOC
>               Relationship", draft-ietf-iasa2-rfc2031bis-00 (work in
>               progress), November 2018.
> 
>    [I-D.ietf-iasa2-trust-update]
>               Arkko, J. and T. Hardie, "Update to the Process for
>               Selection of Trustees for the IETF Trust", draft-ietf-
>               iasa2-trust-update-02 (work in progress), October 2018.
> 
>    [I-D.ietf-mtgvenue-iaoc-venue-selection-process]
>               Lear, E., "IETF Plenary Meeting Venue Selection Process",
>               draft-ietf-mtgvenue-iaoc-venue-selection-process-16 (work
>               in progress), June 2018.
> 
>    [IETF-LLC-A]
>               The Internet Society, "Limited Liability Company Agreement
>               of IETF Administration LLC", August 2018,
>               <https://www.ietf.org/documents/180/
>               IETF-LLC-Agreement.pdf>

Shouldn’t this reference be Normative?   This document does depend on it.

Perhaps some of the other IASA2 related documents as well.

> 
> 
> Haberman, et al.          Expires June 8, 2019                 [Page 23]
> Internet-Draft                    IASA2                    December 2018
> 
> 

. . . . .

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 13 Dec 2018 17:01:33 -0800

Thank you very much, Bob. We'll have to go through this and many of the
changes are quite easy. A couple of first-impression comments inline below
(if I don't comment it's either trivial to change or I don't know the
answer myself):

> Does this doucment also update BCP101?   I think so, if it does, it should
This is probably my misunderstand as being relatively new to IETF (at 5
years!). I had thought by obsoleteing 4071 we naturally obsolete BCP 10 but
it sounds like that's not necessarily the case? I thought those were the
same document.

> Just call this “terminology"?   Do we need to be cute here?
This was copied from 4071, happy to change.

> the rest (IETF LLC) are not.
Ok.

> 2.0.  Perhaps in the future IASA 3.0.
We were trying to disntinguish between IASA 1.0 and IASA 2.0. Do you want
us to just define IASA and not pull out 1.0 vs. 2.0 here?

> for the same thing will be confusing.
I think we're trying to anticipate that people will shorten it. We can
standardize this if that's important.

> have one name.   Either is fine in my view, but not both.
This is apparently a hard thing to satisfy all of you. They are the same
thing... and I'll just s/IETF LLC Executive Director/IETF Executive
Director/g

> Does [formally a multi-member "manager" of the IETF LLC on behalf of ISOC]
> need to be here?  Formal part was defined earlier.
>
>
Yes, this is an important part of the definition that I personally want
here even if it's elsewhere. Hopefully that's ok... is the concern that
it's too opaque? (I could put in an parenthetical to make it a bit more
separate to improve readability?)

> I think it is correct that the IETF Trust is not included here.  Might be
> good to call that out.  That said, where does the IETF Trust get it’s
> funding?
>
>
> I think it would be good that all major decisions are voted on and the
> results are recorded.  This should include budgets, hiring/firing, major
> contracts, selection of IETF meeting venues, etc.
>
>
The thining here like in many boards is that it's not often necessary to
have a vote if there is no dissent... do we need to say voting shall happen
if there is any dissenting opinion? Would be nice to not have a formal vote
unless needed for specific things (adopting budgets, etc.) and not so much
for things like minutes adoption.

> Is this actually legal and consistent with [IETF-LLC-A] and the State of
> Delaware laws regarding LLCs?  I suspect it isn’t.
>
>
This text changed while you were reviewing the document. Can you look at
-01 and tell us if this still stands?

> The degree of consensus will be determined when this document is approved
> via our normal processes (IETF Last Call, IESG review and decision).  This
> text implies it has already happened.
>
> Please revise.
>
>
We had a WG vote at some point I believe at IETF 102 that cemented this in
place although you're certainly right this hasn't made last call. Would
love to get candidate text from you. Due to how things were moving with
Kathy Brown leaving the mechanics here simply didn't allow for IETF last
call, we just can't seem to move that quickly (despite having done all of
this in 2 years, which feels like record time for big things at IETF).

> Does the LLC Board or Executive director do these talks for staff hired by
> the Executive Director.  It should be specified.
>
> . . . . .
>
>
> >
> >
> Who will the liability insurance cover?   I believe that we currently have
> liability insurance down through w.g. chairs.  Will this continue?
>
> >
> I think it would be good if there was stronger text to encourage the IETF
> Chair to serve on the board.  Everything will work better if there is
> closer alignment.
>
>
I doubt we're going to want to mess with this more.

> I am having trouble parsing this, the part that starts with “at least
> one…”   Please rewrite to clarify.  I think it means that a person can not
> serve a third term unless three years has passed, but can’t tell for sure.
>
>
You got it, we can make more clear.

> This whole paragraph could be written to be clearer.  I think it is trying
> to say a vote can be held by people attending a meeting or by email, but
> not a mix of the two.
>
>
> . . . . .
>
>
That would be ISOC's tax return, not the IETF LLC's since it doesn't have
to file its own return.

> Will the tax reports be made available publicly?  I think they should be,
ISOC makes its tax returns and financial reports public. Maybe you mean
IETF LLC-specific financials?

> of ISOC” means.  Please explain.
This means that we send donors a written statement of their tax-exempt
contribution in excess of $75... we will make this more clear:
https://www.irs.gov/charities-non-profits/substantiating-charitable-contributions

> I suggest adding something about also developing a longer term running
> budget (~ 5 years).   Only an annual budget is not enough.
>
> I don’t see anything about debt.  Can the IETF LLC go into debt?   Can it
> borrow money?  Or does it just ask ISOC for more money?
>
> >
> > 7.  IETF LLC Policies
> >
> Suggest adding IAOC developed policies as well.  They were developed over
> the time the IAOC was running and take into account working with the IETF
> community.  We should learn from that experience.
>
> >
> Should the affiliation of LLC directors be transparent?   If they are a
> consultant, should we know who their major source of income is from?
>
> . . . . .
>
> > 7.3.  Compliance
> >

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Dec 2018 15:44:56 +1300

Bob,
On 2018-12-14 13:34, Bob Hinden wrote:
...
> Does this doucment also update BCP101?   I think so, if it does, it should be

That's automatic. This is a BCP that obsoletes RFC4071, which is the base
document of BCP101.
...
> I think it is correct that the IETF Trust is not included here.  Might be good to call that out.  That said, where does the IETF Trust get it’s funding?

I think that for this document, it's simply part of the IETF. No need
to mention it separately.

For the 3rd time: this is yet another reason why we need to bring trust-update back to the WG to make it consistent with rfc4071bis.  

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Thu, 13 Dec 2018 18:58:34 -0800

Brian,

> On Dec 13, 2018, at 6:44 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Bob,

But shouldn’t we be redefining BCP101 to point the the RFC that <draft-ietf-iasa2-rfc4071bis-00> will become?

> to mention it separately.

Is it part of the IETF?  I thought the IETF Trust was a separate legal entity (otherwise it couldn’t hold IPR) and had it’s own bank account.  Seems separate to me.

Also, how is the IETF Trust funded in the IASA 2.0 model?

> For the 3rd time: this is yet another reason why we need to bring trust-update back to the WG to make it consistent with rfc4071bis.

I agree.

Bob

---

From: Brian Carpenter <[email-masked]>
Date: Fri, 14 Dec 2018 16:42:15 +1300

Regards
 Bob,

On Fri, 14 Dec 2018, 15:58 Bob Hinden <[email-masked] wrote:

> But shouldn’t we be redefining BCP101 to point the the RFC that
> <draft-ietf-iasa2-rfc4071bis-00> will become?
>

I'm sure the RFC Editor does that automatically.

> >> I think it is correct that the IETF Trust is not included here.  Might
> be good to call that out.  That said, where does the IETF Trust get it’s
> funding?
> >
> Is it part of the IETF?  I thought the IETF Trust was a separate legal
> entity (otherwise it couldn’t hold IPR) and had it’s own bank account.
> Seems separate to me.
>

Yes, of course, but "the IETF" is a pretty vague concept so it seems like a
detail here, given that we have a dedicated draft for the Trust anyway.

I've been assuming via the LLC.

Regards
    Brian
    (via tiny screen & keyboard)

> >
> > For the 3rd time: this is yet another reason why we need to bring
> trust-update back to the WG to make it consistent with rfc4071bis.
>
> I agree.
>
> Bob
>
>
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 14 Dec 2018 02:47:24 -0500

Some comments on Bob Hinden's comments with things about which
we agree cut out.

First, there have been a set of discussions that go back many
years about the tense in which document drafts that are expected
to become RFCs should be written , e.g., future on the theory
that they are proposals; past on the theory that, when someone
reads the RFC post-publication, that is correct; or present to
describe a state in transition.   I could summarize the opinions
and practices from the distant past, but that would actually not
help and might set off a time-wasting debate.  Can the authors
and/or WG Chairs please have a discussion with the RFC Editor
about what she/they want submitted to them (and what they
propose to adjust), adjust the document accordingly and tell the
rest of us, and move on?

More specific comments below...

--On Thursday, December 13, 2018 16:34 -0800 Bob Hinden
<[email-masked]> wrote:

>...
>>    This document obsoletes [RFC4071], which specified the
>>    original IASA, [RFC4333], which specified the selection
>>    guidelines and process for IAOC members and [RFC7691],
>>    which specified terms for IAOC members.
> 
> Does this doucment also update BCP101?   I think so, if it
> does, it should be mentioned here.

My understanding is that it should become part of BCP101,
replacing 4071 in that role.  But I don't think we have ever
regularized how to do that sort of thing other than by
obsoleting a document that is part of a BCP set and letting the
RFC Editor do their thing.   If more is needed, it should
probably be part of a general discussion of how updates to BCP
numbering are accomplished, rather than something that is
associated with this document in particular and slows it down.

>>    The LLC Agreement between the IETF LLC and ISOC
>>    [IETF-LLC-A] is also out of scope for this document,
>>    however this document depends on the LLC Agreement and
>>    will refer to it for certain aspects of the legal
>>    relationship between the IETF LLC and ISOC.  The LLC
>>    Agreement was developed between legal representatives of
>>    the IETF and ISOC and includes all critical terms of the
>>    relationship, while still enabling maximum unilateral
>>    flexibility for the IETF LLC Board.  The LLC Agreement
>>    includes only basic details about how the IETF LLC Board
>>    manages itself or manages IETF LLC staff, so that the IETF
>>    LLC Board has flexibility to make changes without amending
>>    the agreement.  The
>>    IETF LLC Board can independently develop policy or
>>    procedures documents that fill gaps.

I think I know what that is intended to mean, but, while
"independently develop" may be intended to mean "independent of
the LLC Agreement and independent of ISOC", it could easily be
read as "independent of and with no responsibility to consult
the IETF community or accountability to it".  Recognizing that I
understand the Delaware LLC model puts limits on direct
accountability, I hope it is generally understood that we don't
want any restrictions on accountability beyond what is legally
required.

>> 3.1 Alphabet Soup

I agree with Bob.  Just call this "Terminology".  

Additional suggestion: This subsection is hard and irritating to
read because it mixes terms and are very well known in the
community, terms that are new with the IASA 2.0 changes, and
terms that are becoming obsolete and that, with luck, will be
mostly irrelevant to readers a few years down the line.  Unless
there is a reason for including them that is not obvious to me
(and should be clear to the reader) I suggest dropping IAB,
IESG, IETF, and ISOC.   If anything need be said about them at
all (noting that they are on the RFC Editor's known
abbreviations list), either mention them in passing in the
introductory paragraph to 3.1 and move on or isolate them into a
"General IETF Terminology with Definitions Unchanged"
sub-subsection and introduce that section with a sentence that
makes clear that neither this document nor any other IASA
2.0-related change alters their definitions one bit.  Then
create a sub-subsection called "Terms No Longer in Use with IASA
2.0" or something like that and put "IAD", "IAOC", and maybe
"IETF Executive Director" into it.   So we might end up with

  3.1.1 Terminology Created or Changed by IASA 2.0
  3.1.2 Terminology No Longer in Use
  3.1.3 General IETF Terminology....

In addition...

>>    IAD: IETF Administrative Director, a role obsoleted by
>>    this document and the ISOC/IETF LLC Agreement
>>    ([IETF-LLC-A]) and replaced by the IETF LLC Executive
>>    Director.

I very strongly believe, for reasons explained multiple times,
that "IETF LLC Executive Director" is preferable to "IETF
Executive Director".   However, if that is what we are going to
do, it needs to be internally consistent in this document (it is
not in the current I-D), draft-ietf-iasa2-consolidated-upd must
be updated to match, and all of the documents are are still
floating around as replacement to others that mention the terms,
including the ones that the WG apparently decided should be
processed by the IAB independent of
draft-ietf-iasa2-consolidated-upd must be checked and, if
needed, updated as well. 

At the risk of delivering additional kicks to the proverbial
dead horse, this is another reason I prefer to change
terminology and role definitions via very focused consolidated
update documents rather than replacing multiple separate
documents completely to make small changes.  Not only does it
make the changes more clear (rather than burying them in a great
deal of text that is essentially unchanged) but, if we change
our minds about a small matter of terminology, it makes the
corrections and adjustments really easy.

Also, please think carefully about "replaced by" because, unless
I've misunderstood, there are some IAD functions that don't pass
to the IETF LLC Executive Director.  If that is correct, wording
like "Most of the the functions of the former IAD have been (or
"are now", see above) assigned to the IETF LLC Executive
Director" would be more appropriate.

>...
>>    IETF Administration LLC: The legal entity - a disregarded
>>    Limited Liability Company (LLC) of The Internet Society -
>>    established to house IASA2, specified by the ISOC/IETF LLC
>>    Agreement ([IETF-LLC-A]). Also referred to as "IETF LLC"
>>    or just the "LLC".
> 
> Please, only give it one name, like IETF LLC.   Having
> multiple names for the same thing will be confusing.

And inconsistency between the name in the IETF Administration
LLC Agreement and the term we intend to use throughout the IETF
is not a big problem as long as this document makes the synonym
clear and we are then consistent about the latter.  But more
than those two names is a problem waiting to happen that "the
LLC" or "LLC" would be particularly bad news.
> 
>>    IETF LLC Executive Director: the executive director for
>>    the IETF Administration Limited Liability Company,
>>    responsible for day-to-day administrative and operational
>>    direction (See Section 4.1).  Also referred to as "IETF
>>    Executive Director".  (Note that the title of "IETF
>>    Executive Director" in older documents such as [RFC2026]
>>    is now "Managing Director, IETF Secretariat".)

Essentially the same comment as above.  If this is going to be
"IETF LLC Executive Director", let's use that and not invite
confusion by making it and "IETF Executive Director" equivalent.
If shorter terms are needed, try "IETF LLC ExecDir" rather than
dropping the "LLC" part.

Note too that having multiple terms for the same role is
probably going to require an RFC Style Guide section that
specifies which terms should be used where and probably nits
checker modifications to check for conformance to those rules.
Why invite that sort of trouble and extra work?

> I thought the name was going to be "IETF Executive Director".
> I am fine with now calling it the "IETF LLC Executive
> Director", but it should only have one name.   Either is fine
> in my view, but not both.

See above about my preference... and, in the unlikely event that
is isn't clear, I strongly agree with "not both".

>>    o  The IAD role was replaced with the IETF Executive

See "replaced by" comment above.   I wish the document could get
by without repeating this material.  Repetition just creates
confusion.   One possibility would be to minimize the content of
the suggested Section 3.1.1 (or those definitions if the 3.1.x
subsection model is not adopted) and point to this section for
what happened to those terms.

> .. . . .
>>    The IETF LLC is expected to conduct its work according to
>>    the following principles, subject to any reasonable
>>    confidentiality obligations:
>...

>>    o  Responsiveness to the community.  The IETF LLC is
>>    expected to act consistently with the documented consensus
>>       of the IETF community, to be responsive to the
>>       community's needs, and to adapt its decisions in
>>       response to consensus-based community feedback.

Rathole alert: As far as I know, we have only one mechanism for
obtaining and documenting the consensus of the IETF community.
That involves an IESG-issued and supervised IETF Last Call and
an IESG determination, steps that are defined in terms of the
standards and document approval processes.  Even the IAB asks
for community comment, there is no assumption that what it hears
and how it evaluates that input is "IETF consensus" (documented
or otherwise).  If the intent is that consistency be only with
documents that have gone through formal IESG Last Call, the
document should say that, rather than leaving the question to
handwaving and later debate.   If something broader is intended
(in conjunction with "consensus-based community feedback" or
not) that needs some explanation... and some caution that the
IESG's workload not be unnecessarily increased.   

>>    o  Diligence.  The IETF LLC is expected to act responsibly
>>    so as to minimize risks to IETF participants and to the
>>       future of the IETF as a whole, such as financial risks.
>> 
>>    o  Unification: The IETF LLC is reponsible for providing
>>    unified legal, financial, and administrative support for
>>       operation of the IETF, IAB, IESG, IRTF, and RFC Editor.

> I think it is correct that the IETF Trust is not included
> here.  Might be good to call that out.  That said, where does
> the IETF Trust get it's funding?

Also, what does "unified" mean when the RFC Editor is lumped
together with those other bodies?  In particular, we now have a
situation in which the RFC Production Center is part of the same
organization that operates the Secretariat.  I don't think it is
formally part of the Secretariat although I'd be surprised if
there were not overlaps in "administrative support".  We went to
some effort to be sure those relationships were not requirements
and that the Production Center function could be contracted to a
different entity entirely.  Let's not accidentally make a
significant change by how this is worded. 

>>    o  Transfer or Dissolution: Consistent with [IETF-LLC-A],
>>    the IETF LLC subsidiary may be transferred from ISOC to
>>       another organization, at the request of either party.

ISOC is clearly one of the parties.  Who is the other one?  It
probably cannot be the IETF Administration LLC Board
unilaterally declaring independence.  I presume it cannot be
some external third party deciding that the IETF Administration
LLC should belong to it and requesting that transfer.  So what
does this mean in practice?

>>       Similarly, the IETF LLC may be dissolved if necessary.
>>       Should either event occur, the IETF community should be
>>       closely involved in any decisions and plans, and any
>>       tranfer, transition, or dissolution conducted carefully
>>       and with minimal potential disruption to the IETF.

Realistically, unless this whole thing turns out, in practice,
to be a bad idea and we embark on IASA 3.0, the most likely
reason to dissolve the IETF LLC is that the IETF itself implodes
or fades into irrelevancy.   Should that be the case,
consulting/involving the IETF community would be hard and
potential disruption to the IETF irrelevant.   A more
interesting question is whether the IETF LLC Board would have
the ability to dissolve the IETF :-(

> .. .  . .
>> 3.8.  Review and Appeal of IETF Executive Director and IETF
>> LLC Board Decisions
>> 
>>    The IETF LLC Board is directly accountable to the IETF
>>    community for the performance of the IASA 2.0.  In order
>>    to achieve this, the IETF LLC Board and IETF Executive
>>    Director are expected to ensure that guidelines are
>>    developed for regular operational decision making. Where
>>    appropriate, these guidelines should be developed with
>>    public input.  In all cases, they must be made public.
> 

And, remembering that this is about guidelines and not, e.g.,
contract specifics or detailed personnel actions, what are
examples of situations in which public input would be
inappropriate in setting guidelines?   

Editorial (I hope): "IETF Executive Director" ->  "IETF LLC
Executive Director".

> .. . . . .
>>    For the first slot listed above, the presumption is that
>>    the IETF Chair will serve on the board.  At the IESG's
>>    discretion, another area director may serve instead, or
>>    exceptionally the IESG may run a selection process to
>>    appoint a director.  The goal of having this slot on the
>>    board is to maintain coordination and communication
> I think it would be good if there was stronger text to
> encourage the IETF Chair to serve on the board.  Everything
> will work better if there is closer alignment.

I think the text is adequate.  Further would slide toward
requiring the IETF Chair to serve.  If, for example, the Nomcom
decides to put someone into the IETF Chair position who does not
have the support needed to dedicate full-time to the job, giving
the IESG flexibility to put another of their members into the
position makes sense.  It is to be hoped that whomever serves in
the slot that appears to be essentially a representative of the
IESG would do so with regular consultation with that body (even
if that person is the IETF Chair).  Perhaps that is what needs
to be more explicit.

> .. . . . .

>>    When the IETF LLC conducts fundraising, it substantiates
>>    charitable contributions on behalf of ISOC.
> 
> I don't understand what "substantiates charitable
> contributions on behalf of ISOC" means.  Please explain.

Just a guess, based on what we have been told before: ISOC
itself could be in tax trouble if almost all of its income came
from one or more wholly-owned for-profit subsidiary such as PIR.
This is intended to make sure that any funds the IETF collects
("from fundraising", whatever that means) can be listed on
ISOC's accounts as charitable contributions _to ISOC_ that help
balance the profits from the cash cow.    I don't see a problem
with this if it is considered legal, but wonder whether it would
compromise the IETF LLC's independence in any way.   If nothing
else, it would give ISOC an incentive, perhaps a significant
one, to not allow the IETF LLC to move itself to another home.
That makes getting the material under "Transfer or Dissolution"
... :at the request of either party" right extra-important
because, if the IETF LLC is transferred to another body, the
above paragraph is possibly either a no op or tax fraud.
 
> Should the affiliation of LLC directors be transparent?   If
> they are a consultant, should we know who their major source
> of income is from?

Be a bit careful here.  I don't know if I'm typical, but to
provide a concrete example, I'm someone who has been a
consultant of the multiple client variety (rather than the
employee in disguise variety) for many years, I've often had
contracts that prevent disclosure of the relationship or what
I'm doing for that particular client except in the broadest and
most generic terms.  I've also never had a client who
contributed more than 25% of my income in a given year, so
wouldn't know how to answer a question about my major source of
consulting income.  

I don't believe that I have taken a consulting contract in the
last 15 or more years where the work involved developing or
influencing IETF standards or other work, so probably don't have
even potential conflicts of interest from that source.   Using
that as an example, if the community is going to impose more
stringent requirements on transparency and disclosure, the text
should be worded very carefully if the desire includes not
excluding people from candidacy as a unnecessary and undesirable
side effect.
 
> .. . . . .
>> 10.  IANA Considerations
>> 
>>    This document has no IANA considerations in the
>>    traditional sense. However, some of the information in
>>    this document may affect how the IETF standards process
>>    interfaces with the IANA, so the IANA may be interested in
>>    the contents.

We have a separate document that is supposed to describe the
IASA - IANA relationship.  It should probably be normatively
referenced from this section and the hand waving ("may affect")
dropped or qualified.   If there really is anything in here that
affects the interactions of the IETF standards process and IANA,
it almost certainly belongs there. 

best,
   john

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Fri, 14 Dec 2018 06:02:25 -0800

Thank you, John!

I can't emphasize enough how important these reviews are and really
appreciate the feedback from all that have pitched in over the past few
days.

What we'll do is carefully distill this discussion into either direct
changes to the document where it's clear what to do (e.g., s/IETF Executive
Director/IETF LLC Executive Director/g) or we'll establish individual
github issues to track edits that need more discussion and Jason or I will
bring those here to the WG list as individual threads.

I'll wait until Saturday to do this so discussion can continue today. Best
and thank you, Joe

Joseph Lorenzo Hall

---

From: Bob Hinden <[email-masked]>
Date: Fri, 14 Dec 2018 09:18:10 -0800

Hi Brian,

> On Dec 13, 2018, at 7:42 PM, Brian Carpenter <[email-masked]> wrote:
> 
> 
> 
> Regards
>  Bob,
> 

Not sure, but I think it would better to say it explicitly here.

> Yes, of course, but "the IETF" is a pretty vague concept so it seems like a detail here, given that we have a dedicated draft for the Trust anyway.

Yes, “the IETF” is still a vague concept :-)

However, as I note below, we should know how the Trust is funded.

> I've been assuming via the LLC.

Can someone answer the question who knows and/or point to a document that says it?   If it’s the LLC, then I think this document should say it.

Thanks,
Bob

---

From: Bob Hinden <[email-masked]>
Date: Fri, 14 Dec 2018 10:16:07 -0800

Joe,

Happy to help.

A few comments on your comments below.  I will trim the reply.

Thanks,
Bob

————

> This is probably my misunderstand as being relatively new to IETF (at 5 years!). I had thought by obsoleteing 4071 we naturally obsolete BCP 10 but it sounds like that's not necessarily the case? I thought those were the same document.
> 

As the discussion with Brian Carpenter, I think BCP 101 should be changed to point to this document.

> We were trying to disntinguish between IASA 1.0 and IASA 2.0. Do you want us to just define IASA and not pull out 1.0 vs. 2.0 here?
> 

Understood.  IASA is the general term that includes current, 2.0 and future models, if the document needs to point back to IASA 1.0, then use that as a term.

> I think we're trying to anticipate that people will shorten it. We can standardize this if that's important.
> 

Yes, please.

> Yes, this is an important part of the definition that I personally want here even if it's elsewhere. Hopefully that's ok... is the concern that it's too opaque? (I could put in an parenthetical to make it a bit more separate to improve readability?)

I was just noting it was said earlier, and wasn’t sure if needed to be repeated.  It does no harm to repeat it.

> The thining here like in many boards is that it's not often necessary to have a vote if there is no dissent... do we need to say voting shall happen if there is any dissenting opinion? Would be nice to not have a formal vote unless needed for specific things (adopting budgets, etc.) and not so much for things like minutes adoption.
> 

I was on the ISOC Board for six years, and chair for three.   Individual votes were always recorded for major items, a summary other actions, and others approved by acclamation.  In all cases there is a motion and second, and all are recored in the minutes.

For example, the ISOC Board minutes for it’s meeting on July 1, 2018:

  https://www.internetsociety.org/board-of-trustees/minutes/

Some examples:

- Moved by Hiroshi, seconded by Desiree. Passed unanimously.

- Moved by Harish, seconded by Olga. Passed 10-0, with Sean and Hans Peter abstaining.

- Moved by Richard, seconded by Sean. Approved by acclamation.

- Moved by Walid, seconded by Pepper.
    Desiree Yes
    Glenn Yes
    Gonzalo Yes
    Hans Peter Yes
    Harish Yes
    Hiroshi Yes
    John Yes
    Olga Yes
    Pepper Yes
    Richard Yes
    Sean Yes
    Walid Yes
The motion passed unanimously.

I think this is a good model for the IETF LLC Board.

> This text changed while you were reviewing the document. Can you look at -01 and tell us if this still stands?

Yes, the whole paragraph on “exceptional cases” was removed.

> We had a WG vote at some point I believe at IETF 102 that cemented this in place although you're certainly right this hasn't made last call. Would love to get candidate text from you. Due to how things were moving with Kathy Brown leaving the mechanics here simply didn't allow for IETF last call, we just can't seem to move that quickly (despite having done all of this in 2 years, which feels like record time for big things at IETF).
> 

As I am sure you know, nothing is certain in the IETF until a document has had an IETF Last Call.   I still find it troubling that we went ahead with IASA 2.0 without following our normal process, even though I understand the time pressures.

The simplest thing for this document would be to remove the Section entirely.  It’s not needed for what the document is intending to do.  I can’t think of any other document that has text like this.  The IESG can declare a consensus later when it is approved.

---

From: "John Levine" <[email-masked]>
Date: 14 Dec 2018 13:20:27 -0500

>> I've been assuming via the LLC.

Good guess, but wrong.

>this document should say it.

The Trust is funded by multiple donors, of which ISOC has been one and
the the LLC will be one.  We also make a small amount from fees paid
by lawyers who want authenticated copies of IETF documents, typically
for patent cases.

One of the things that the trustees do is to ask other people for
money.  We're a separate organization with a separate budget from the
LLC, and we publish a Form 990 separate from ISOC's.  We think it's
important to have multiple funders to establish our independence from
ISOC and now from the LLC.  Our budget is cleverly hidden under the
Budget link on the Trust website's home page.

I am having trouble imagining why anyone thinks this document should
get into any of this.  RFCs 4071 and r371 don't.

For the 103rd time, please resist the urge to overspecify needless details.

R's,
John

---

From: Bob Hinden <[email-masked]>
Date: Fri, 14 Dec 2018 10:45:50 -0800

John,

> On Dec 14, 2018, at 10:20 AM, John Levine <[email-masked]> wrote:
> 

Thanks.

> For the 103rd time, please resist the urge to overspecify needless details.

If the IETF Trust is not primarily funded by the LLC, then I think the current text in 4071bis about who the LLC does support is fine.

Bob

> 
> R's,
> John
> 
> _______________________________________________
> iasa20 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iasa20

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Dec 2018 07:46:36 +1300

> get into any of this.  RFCs 4071 and r371 don't.

I tend to agree. If we didn't need to discuss Trust funding in
the trust-update draft, why discuss it here? This isn't primarily
about the Trust.

Regards
   Brian

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 17 Dec 2018 08:48:14 -0500

> On Dec 14, 2018, at 1:45 PM, Bob Hinden <[email-masked]> wrote:
> 

For reference, the 2019 Trust budget is available at https://trustee.ietf.org/documents/IETF_Trust_2019_Budget_Final.pdf.

Alissa

---

From: Bob Hinden <[email-masked]>
Date: Mon, 17 Dec 2018 08:52:13 -0800

Alissa,

> On Dec 17, 2018, at 5:48 AM, Alissa Cooper <[email-masked]> wrote:
> 
> 
> 

Thanks, very helpful.   Now some questions based on this document.  The forecast for 2018, budget for 2019 and advice for later years shows:

Income
                         2018        2019       2020       2021
IETF LLC Contribution  $63,596     $65,258    $65,500    $48,650
Other Contributions      7,858      20,000     20,000     20,000
Misc                    $1,500           0          0          0

This looks like the majority of funding is from the LLC.   Specifically, 87% in 2018 and 77% going forward.

Based on this, I think 4071bis should mention the IETF Trust as it appears to be the primary source of funding for the IETF Trust.

Also, where are the “Other contributions” intended to come from?

Thanks,
Bob

---

From: "John R Levine" <[email-masked]>
Date: 17 Dec 2018 11:54:49 -0500

> This looks like the majority of funding is from the LLC.   Specifically, 87% in 2018 and 77% going forward.

Yes, that is true.

> Also, where are the “Other contributions” intended to come from?

Other organizations we know.  Why in the world would this go into an RFC?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Bob Hinden <[email-masked]>
Date: Mon, 17 Dec 2018 09:03:26 -0800

John,

> On Dec 17, 2018, at 8:54 AM, John R Levine <[email-masked]> wrote:
> 
> Other organizations we know.

Can we say their names?

> Why in the world would this go into an RFC?

Of course that wouldn’t, but I think 4071bis should mention that the LLC provides support for the IETF Trust.  Much the same reason the other groups are listed:

Though I think in this case, just saying financial support would be more accurate.

Bob

---

From: "John R Levine" <[email-masked]>
Date: 17 Dec 2018 12:20:17 -0500

>> Other organizations we know.

One is RIPE, I think another is still doing paperwork.

> Though I think in this case, just saying financial support would be more accurate.

If it's going to be there at all, I'd rather "partial financial support", 
since the point of having other donors is to avoid the appearance the the 
trust is in practice a wholly owned and funded subsidiary of ISOC.

Regards,

---

From: Bob Hinden <[email-masked]>
Date: Mon, 17 Dec 2018 09:22:33 -0800

> On Dec 17, 2018, at 9:20 AM, John R Levine <[email-masked]> wrote:
> 
> If it's going to be there at all, I'd rather "partial financial support", since the point of having other donors is to avoid the appearance the the trust is in practice a wholly owned and funded subsidiary of ISOC.

I am fine with that for the reason you state.

Bob

---

From: Ted Hardie <[email-masked]>
Date: Mon, 17 Dec 2018 09:41:53 -0800

Howdy,

On Mon, Dec 17, 2018 at 9:22 AM Bob Hinden <[email-masked]> wrote:

> > If it's going to be there at all, I'd rather "partial financial
> support", since the point of having other donors is to avoid the appearance
> the the trust is in practice a wholly owned and funded subsidiary of ISOC.
>
I don't see the reason to state this in RFC 4071bis; the IETF Trust is a
separate legal entity and the choice to provide support to it will be up to
the relevant folks at whatever orgs choose to provide support.  That will
be the IETF LLC Board for the IETF LLC.  Writing down that the IETF LLC
board currently provides support doesn't belong in an archival document at
this level.  It belongs in budgets and minutes.

If you write down that it *must* provide support, you are both undermining
the IETF LLC board and may be opening the question of whether it is truly
independent.  Neither are worth doing  in my opinion.

Ted
(No hats, and no cattle)

---

From: Portia Wenze-Danley <[email-masked]>
Date: Mon, 17 Dec 2018 12:42:41 -0500

________________________________
Portia Wenze-Danley
IETF Administration LLC Executive Director (Interim)
(Formerly IETF Administrative Director (IAD)	
Internet Engineering Task Force (IETF)
[email-masked]

> On Dec 17, 2018, at 12:22 PM, Bob Hinden <[email-masked]> wrote:
> 
> 

	Google will appear as a contributor on the 2018 Oct statement once approved for posting.  We anticipate a contribution in 2019 as well.

---

From: "John R Levine" <[email-masked]>
Date: 17 Dec 2018 12:45:47 -0500

> independent.  Neither are worth doing  in my opinion.

By golly, he's right.

Regards,

---

From: Bob Hinden <[email-masked]>
Date: Mon, 17 Dec 2018 09:54:11 -0800

Ted,

> On Dec 17, 2018, at 9:41 AM, Ted Hardie <[email-masked]> wrote:
> 
> Howdy,
> 
> I don't see the reason to state this in RFC 4071bis; the IETF Trust is a separate legal entity and the choice to provide support to it will be up to the relevant folks at whatever orgs choose to provide support.  That will be the IETF LLC Board for the IETF LLC.  Writing down that the IETF LLC board currently provides support doesn't belong in an archival document at this level.  It belongs in budgets and minutes.

I don’t follow.  It currently says the IETF provides support for, for example, the IRTF.   Why is this different?

> 
> If you write down that it *must* provide support, you are both undermining the IETF LLC board and may be opening the question of whether it is truly independent.  Neither are worth doing  in my opinion.

Saying that the LLC provides partial support for the IETF Trust makes it clear it is intended to do so, and also says it’s not providing all of the support.

If it’s not listed in this document, under what authority does the LLC have to provide money to the IETF Trust?

This seems to be a odd discussion, since looking at the budget the LLC is providing ~3/4 of the support for the IETF Trust.  That is apparently the current reality.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Dec 2018 07:45:49 +1300

>> independent.  Neither are worth doing  in my opinion.

The IETF LLC Board is supposed to be responsive to the expectations of
the IETF community. As a member of that community, I for one expect the
LLC to provide backstop support for the IETF Trust, even if others
are chipping in. So I don't see any undermining in stating it, as in
the current draft. I suggest leaving the text as it is now.

    Brian

---

From: "John R Levine" <[email-masked]>
Date: 17 Dec 2018 13:52:41 -0500

> the current draft. I suggest leaving the text as it is now.

If you'll reread Ted's comments, you'll see that the proposed text is 
potentially harmful to the trust and quite possibly wrong.

We expect the LLC to fund the trust for the forseeable future but if, as a 
hypothetical example, it got a chunk of money from the ICANN auction fund 
or elsewhere sufficient to endow it, the LLC wouldn't need to any more.

For the 104th time, can we please resist the urge to overspecify things.

Regards,

---

From: Ted Hardie <[email-masked]>
Date: Mon, 17 Dec 2018 12:20:45 -0800

On Mon, Dec 17, 2018 at 9:54 AM Bob Hinden <[email-masked]> wrote:

> I don’t follow.  It currently says the IETF provides support for, for
> example, the IRTF.   Why is this different?
>
>
>
Just to be crystal clear, the IETF LLC provides support for the IRTF and
IAB, as well as the IETF.  Those are entities whose budgets are all handled
by the IETF LLC process.

The IETF Trust is a separate legal entity.   It has a distinct budget
process, set of donors, and set of potential liabilities.  We don't want
that being confused, and setting in stone that the IETF LLC contributes to
it confuses the issue.

Ted

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Dec 2018 09:25:33 +1300

> potentially harmful to the trust and quite possibly wrong.

Maybe. But that's not what I said. I said "leave the text as it is now."
Now, it says:

To my mind that covers the Trust, as part of 'operation of the IETF'.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Mon, 17 Dec 2018 12:44:25 -0800

Ted, Brian,

I will try one reply, since both relate to the same issue.

> On Dec 17, 2018, at 12:20 PM, Ted Hardie <[email-masked]> wrote:
> 
> Just to be crystal clear, the IETF LLC provides support for the IRTF and IAB, as well as the IETF.  Those are entities whose budgets are all handled by the IETF LLC process.

Agreed.

> 
> The IETF Trust is a separate legal entity.   It has a distinct budget process, set of donors, and set of potential liabilities.  We don't want that being confused, and setting in stone that the IETF LLC contributes to it confuses the issue.

Understood, but I am not proposing to “setting it into stone”, just that it is OK for the LLC to fund the IETF Trust (especially since it is happening now).

You didn’t answer my other question, "If it’s not listed in this document, under what authority does the LLC have to provide money to the IETF Trust?”

As you note, the IETF Trust is a separate legal entity.  It’s not part of IETF, IAB, IESG, IRTF, and RFC Editor.

> 
> On Dec 17, 2018, at 12:25 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> 
> To my mind that covers the Trust, as part of 'operation of the IETF’.

As Ted notes correctly, the IETF Trust is a separate legal entity, and is not part of the IETF, IAB, IESG, IRTF, and RFC Editor.

Are there any limits on what the LLC can use it’s money for?

Bob

---

From: Ted Hardie <[email-masked]>
Date: Mon, 17 Dec 2018 13:00:48 -0800

On Mon, Dec 17, 2018 at 12:44 PM Bob Hinden <[email-masked]> wrote:

> T
> Understood, but I am not proposing to “setting it into stone”, just that
> it is OK for the LLC to fund the IETF Trust (especially since it is
> happening now).
>
>
The contrary question is "Why does this need to be written into an RFC"?
Clearly, I do think it is appropriate for the LLC to provide funding to the
IETF Trust, as I helped prepare and approve a budget that did so.  But I
also think that future boards will consider the question and make sensible
decisions here without having to have it put in this document.  As John
notes, there may be years where it is not necessary or desirable, and I'd
like to leave it to them.

> You didn’t answer my other question, "If it’s not listed in this document,
> under what authority does the LLC have to provide money to the IETF Trust?”
>
Because the IETF LLC receives a license to the marks held by the IETF
Trust, it is in the interest of the LLC to make sure those marks are
correctly registered and maintained.  That's the job the LLC does.  We
could structure this differently (as a fee paid by the IETF LLC to the
Trust, as an example), but given that both are non-profit entities, a
donation seems a reasonable way to express the support.

What we don't want here is for the two entities to get conflated, because
that muddies the waters about which entity is liable for what.

Ted

> As Ted notes correctly, the IETF Trust is a separate legal entity, and is
> not part of the IETF, IAB, IESG, IRTF, and RFC Editor.
>

---

From: "John R Levine" <[email-masked]>
Date: 17 Dec 2018 16:04:29 -0500

> To my mind that covers the Trust, as part of 'operation of the IETF'.

So long as we agree that the result is that we should leave the text 
alone, OK.

Regards,

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 17 Dec 2018 21:10:58 +0000

I see the replies are still coming in. As noted a moment ago in a renamed thread ("Re: [Iasa20] Trust Funding (was: Comments on <draft-ietf-iasa2-rfc4071bis-00>)"):
Thanks everyone for the discussion of the IETF Trust's funding sources. I think the consensus is that expressly mentioning IETF Trust funding in an RFC could be overly limiting, and that the annual budget items of the IETF LLC do not need to be listed in an RFC either. It also seems that RFC 4071-bis does say correctly that the details of the IETF Trust are out-of-scope for the document, and points to draft-ietf-iasa2-trust-update. As a result, no changes to 4071-bis in this area seem necessary.

JL 

On 12/17/18, 4:04 PM, "iasa20 on behalf of John R Levine" <[email-masked] on behalf of [email-masked]> wrote:

    
    Regards,

---

From: "John Levine" <[email-masked]>
Date: 17 Dec 2018 16:36:36 -0500

>Are there any limits on what the LLC can use it’s money for?

Of course.  See section 4 of the operating agreement.  There's nothing
surprising, to somewhat oversimplfy, it has to be consistent with its
tax exempt status, and it has to support IETF, IAB, and IRTF.  Section
11 has a list of specific obligations about keeping adequate financial
and management controls.

R's,
John

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 18 Dec 2018 07:44:25 -0500

Bob suggested the following and I wanted to bring it to the list:

> borrow money?  Or does it just ask ISOC for more money?

Can I get wider comment as to whether or not we should specify that the
IETF LLC should keep a longer-term running budget as Bob suggests above?

I think it's pretty obvious on the debt side from Section 4.3, but perhaps
this could be made more clear or repeated in the budget section?:

      financial and business stability that it needs to be able to meet
      the needs of the IETF, including adopting an annual budget, and as
      necessary incurring any debt or making other financial
      arrangements;```

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 18 Dec 2018 13:21:15 +0000

*   Can I get wider comment as to whether or not we should specify that the IETF LLC should keep a longer-term running budget as Bob suggests above?

Channeling for John :) I think it’s wrong to over-specify and the current text is sufficient.

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 18 Dec 2018 08:47:38 -0500

One fact to note is that the initial annual contribution commitments from ISOC are for the first two years, with a funding re-assessment required by September 1, 2020 (LLC Agreement Exhibit B). So that might make a meaningful 5-year plan difficult at present.

Alissa

> On Dec 18, 2018, at 7:44 AM, Joseph Lorenzo Hall <[email-masked]> wrote:
> 
> On Thu, Dec 13, 2018 at 7:34 PM Bob Hinden <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> ....
> Can I get wider comment as to whether or not we should specify that the IETF LLC should keep a longer-term running budget as Bob suggests above?
> 
> I think it's pretty obvious on the debt side from Section 4.3, but perhaps this could be made more clear or repeated in the budget section?:

---

From: Glenn Deen <[email-masked]>
Date: Tue, 18 Dec 2018 06:51:34 -0800

Sent from my iPad

> On Dec 18, 2018, at 4:44 AM, Joseph Lorenzo Hall <[email-masked]> wrote:
> 
First, I’ve found the long term budgets done by orgs to be very detached from reality.  This is because unless you have anything more than a turn key operations budget that contains basically the same income and costs year after year, a 5 year budget won’t reflect reality and will deviate significantly as the organization makes decisions, and as economic changes impact things such as meeting attendance and sponsorships, and those major events are impossible to predict.

Yes, a five year outlook budget works well if you are managing a real estate management business, or something that is capital heavy where you can project that in year X you need to invest in renovations, or appliance replacements, or some other predictable capital investment with a nice predicable write down. 

That’s where long term budgets are valuable because they capture and highlight events that take place at periods longer than 1-2 years.  Things like a new boiler for a building at 20 years for instance.  The ietf simply does not have these sort of long period budget items that are significant when compared with the year to year meeting costs and meeting revenues which dominate the budget.

I don’t see the return for the effort benefit to the IETF budget which has its biggest items as meeting revenues and costs and around sponsors willing to sponsor and attendees attend and changes at that level won’t be reflected in 5 year budget will simply likely contain basic year to year increases and will assume conditions will just keep steady year over year as you can’t predict the major economic events that would produce impact to the ietf like back in 2001 and 2009 where attendance and sponsorships got hit hard by the economy.  

Glenn

---

From: "John Levine" <[email-masked]>
Date: 18 Dec 2018 15:57:18 -0500

In article <CABtrr-U4z9W4UtxQ9+xSSV6eN=[email-masked]> you write:
W>> I suggest adding something about also developing a longer term running
>> borrow money?  Or does it just ask ISOC for more money?

Why would anyone think that we can answer these questions today, in
the complete absence of information, better than the LLC board could
at the time if and when the questions arise?  Given the gigantic size
of the LLC's reserve it's hard to imagine them needing to borrow money
to fund the IETF, but it's also not hard to imagine a situation where
some sort of short term loan to time payments or forex would make
sense.  

For the 106th time, can we please refrain from micromanaging
hypothetical situations? Let the board do its job.

>IETF LLC should keep a longer-term running budget as Bob suggests above?

Now the 107th time.  If we don't believe the LLC board will act
reasonably, we need to fix the process for selecting the board, not
try to turn them into robots.

R's,
John

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 18 Dec 2018 22:28:10 +0000

It's hard because it goes against the experience of programmers and protocol designers, where everything must be specified.

---

From: "John R Levine" <[email-masked]>
Date: 18 Dec 2018 17:52:49 -0500

> It's hard because it goes against the experience of programmers and 
> protocol designers, where everything must be specified.

Indeed, but we can try and resist the urge, and remember that the people 
who are interpreting our plans will probably be as smart as we are, and 
definitely better informed because they will know what has happened 
between now and whenever they have to decide what they're deciding.

There's a whole underexplored area of how law and contracts are like or 
unlike software.  For your amusement, here's a story about a legal 
version of a code coverage bug:

https://www.vice.com/en_us/article/zn8nnw/theres-a-50-square-mile-section-of-yellowstone-where-you-can-get-away-with-murder

Regards,

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 19 Dec 2018 06:14:14 +0200

>> borrow money?  Or does it just ask ISOC for more money?
IMO, no debts for IETF LLC (if must limited by conditions and level of
amount), but only borrows from ISOC within agreed period (less than 6
months).

> IETF LLC should keep a longer-term running budget as Bob suggests above?

I disagree, for a new organisation we need only annual, but if
succeed within 5 years long then we can start longer-term budgets. It is
important to know that companies do fail so we plan for less periods.

>       necessary incurring any debt or making other financial
I think it is not clear, and needs to specify conditions of debts as ALL
companies have.

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 19 Dec 2018 06:31:47 +0200

On Mon, Dec 17, 2018 at 6:52 PM Bob Hinden <[email-masked]> wrote:

> >> If the IETF Trust is not primarily funded by the LLC, then I think the
> current text in 4071bis about who the LLC does support is fine.
> >
> > For reference, the 2019 Trust budget is available at
> https://trustee.ietf.org/documents/IETF_Trust_2019_Budget_Final.pdf.
>
> Thanks, very helpful.   Now some questions based on this document.  The
> forecast for 2018, budget for 2019 and advice for later years shows:
>
> Income
>                          2018        2019       2020       2021

I advise that we focus that the budget is for one year because we may get
more funding from more contributors,

> Based on this, I think 4071bis should mention the IETF Trust as it appears
> to be the primary source of funding for the IETF Trust.
>

other contributions depend on the IETF LLC company future relationship and
the future work per month, the IETF LLC needs more contributors from more
organisations that support IETF.

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 19 Dec 2018 06:34:07 +0200

+1

AB

On Mon, Dec 17, 2018 at 10:21 PM Ted Hardie <[email-masked]> wrote:

>> > I don't see the reason to state this in RFC 4071bis; the IETF Trust is
>> a separate legal entity and the choice to provide support to it will be up
>> to the relevant folks at whatever orgs choose to provide support.  That
>> will be the IETF LLC Board for the IETF LLC.  Writing down that the IETF
>> LLC board currently provides support doesn't belong in an archival document
>> at this level.  It belongs in budgets and minutes.
>>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Dec 2018 17:28:13 -0500

John Levine <[email-masked]> wrote:
    > Why would anyone think that we can answer these questions today, in the
    > complete absence of information, better than the LLC board could at the
    > time if and when the questions arise?  Given the gigantic size of the
    > LLC's reserve it's hard to imagine them needing to borrow money to fund

Is the proposed budget for 2019 public yet? :-)

I can see why people might ask the question at this point, especially if they
don't know about this.

I don't think we need to have an answer in a document, but I think the LLC
board should tell the community an answer.

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

---

From: "John R Levine" <[email-masked]>
Date: 19 Dec 2018 17:54:32 -0500

> board should tell the community an answer.

I wouldn't disagree, but keep in mind that the LLC board is still the 
initial benchwarmers.

Regards,

---

From: Bob Hinden <[email-masked]>
Date: Wed, 19 Dec 2018 15:01:11 -0800

John,

> On Dec 18, 2018, at 12:57 PM, John Levine <[email-masked]> wrote:
> 

Forgive me for not being into the details of all of this as you are.

I read the draft and had some comments and questions.   I wasn’t suggesting that everything had to be specified in this document, some were just questions.

Bob