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

[John C Klensin <[e-mail]>]

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