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

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

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

On Thu, Dec 13, 2018 at 23:47 John C Klensin <[e-mail]> wrote:

> 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
> <[e-mail]> 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.
>
> >> 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
> >>    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.  Definitions and Principles
>
> >> 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
> >>    Director role.
>
> 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.
>
> > .. . . .
> >
> >> 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  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.
> >
> > Why is the IETF Executive Director called out here?   Is there
> > a distinction?  Please explain?
>
> 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
> >>    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.
>
> 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.
>
> > .. . . . .
>
> >> 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.
>
> 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.
>
> >...
> >> 7.1.  Conflict of Interest Policy
> >...
> > 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
>
> --
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [e-mail], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871