Subject: [Iasa20] The consolidated update draft - draft-ietf-iasa2-consolidated-upd

From: John C Klensin <[email-masked]>
Date: Thu, 15 Nov 2018 15:21:24 -0500

Hi.

With a huge amount of help from Jason, I'm about to post the
proposed draft for consolidated updates for name and title
changes due to the IASA 2.0 process.  For cleanliness and the
avoidance (or at least reduction) of confusion, it also includes
explicitly obsoleting a number of Experimental and Informational
documents that are irrelevant at this point and recommending
that they be reclassified to Historic.  If there are aspects of
this draft that seem wrong, blame me, not Jason (he will see
this version only when it is posted) or, better than blaming
anyone, point out the problems and suggest text for fixes.

Some comments and warnings (important):

* This is still a very rough draft.   I had some issues with a
few of Jason's suggestions and he apparently had some with mine.
I've sorted those things out to the best of my ability without
further delaying getting this posted, but there are several
notes in the text to which people should pay careful attention
and it should be read on the assumption that it contains errors
and/or omissions.

* The more I dug into the implications of switching titles
around, the more concerned I've gotten about confusion that I
fear will be with us for many years to come [1].  As Alissa has
pointed out on this list, the new use of "Executive Director" is
baked into the LLC agreement
(https://www.ietf.org/documents/180/IETF-LLC-Agreement.pdf), so
we probably need to learn to live with it.  However, we are
going to need to be very clear about documents and relationships
and provide explanations when they might be needed by people who
are not completely familiar with the LLC transition work, but to
watch, for many years, every single new document (whether from
the WG or later) that uses either title to be sure it is used
correctly.   I'd even recommend putting a check into the I-D
Nits Checker to flag such uses for careful checking.   There is
a small rant about this is in comment in the I-D; we can remove
it later.

* As another opportunity for terminology confusion that is going
to require careful attention, everyone should note that the
second word in the expansion of "IASA" (for the original
version, version 2.0, the name of the WG, etc.) and "IAOC" is
"Administrative" while the term in the name of the LLC is
"Administration".   I've seen several things go by that say
"IETF Administrative LLC".  THey are wrong and need to be
corrected.

* As a further issue with the Executive Director title, there is
no longer any such thing as an "IETF Executive Director" unless
one applies a creative reading to the "may do business as" text
in Section 1(b) of the LLC Agreement.   IANAL, so have no
opinion about whether such a reading would be permissible but it
would certainly create more confusion about any boundaries
between the LLC and the IETF.  So we should probably get rid of
any references to "IETF Executive Director" when they refer to
the "Executive Director of the IETF Administration LLC".   That
will require some further updates to other documents; the
current I-D certainly does not have it right and is not
complete.   This is also partially covered by the rant referred
to above.

* This draft uses the term "deprecate", which has no specific
meaning in the IETF, to refer to obsoleting a document and
recommending that it be reclassified to Historic.   If anyone
doesn't like that, suggest text.

* I am posting the XML for those who want it, github fans, etc.,
but note that the XML for this version is full of commented-out
alternate text, notes to myself, placeholders for the next
version, etc.  Some of those comments will be quite cryptic if
you don't know how I have been developing documents since the
summer of 1999 -- best to just ignore them.

best, 
   john

[1] I have been reflecting on some recent personal experience
that interacts with the IETF and these documents.  Some years
ago and for reasons completely unrelated to the IETF and its
work, I signed up for a citation-tracking service called
Research Gate.  The people here with academic ties will know
about it and/or its several competitors.  For the benefit of
those who don't, one of  the things they do is to tell me every
time something that has my name on its as an author shows up in
a citation in a paper they find out about.  What I have found
interesting from an IETF / RFC standpoint is that, more than ten
years after RFC 5321 replaced RFC 2821, the earlier document is
still being referenced in papers more often than the current
one.  These things _never_ go away.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 15 Nov 2018 15:31:51 -0500

> complete.   This is also partially covered by the rant referred

Yes, the IETF Adminstration LLC does business as "IETF", if I recall
correctly, and so the two phrases "IETF Executive Director" and "IETF
Administration LLC Executive Director" are equivalent. Or am I missing your
point here?

> _______________________________________________
> iasa20 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iasa20
>
-- 
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: John C Klensin <[email-masked]>
Date: Thu, 15 Nov 2018 16:11:06 -0500

--On Thursday, November 15, 2018 15:31 -0500 Joseph Lorenzo Hall
<[email-masked]> wrote:

>> * As a further issue with the Executive Director title, there
>> is no longer any such thing as an "IETF Executive Director"
>> unless one applies a creative reading to the "may do business
>> as" text in Section 1(b) of the LLC Agreement.   IANAL, so
>> have no opinion about whether such a reading would be
>> permissible but it would certainly create more confusion
>> about any boundaries between the LLC and the IETF.  So we
>> should probably get rid of any references to "IETF Executive
>> Director" when they refer to the "Executive Director of the
>> IETF Administration LLC".   That will require some further
>> updates to other documents; the current I-D certainly does
>> not have it right and is not complete.   This is also
>> partially covered by the rant referred to above.

> Yes, the IETF Adminstration LLC does business as "IETF", if I
> recall correctly, and so the two phrases "IETF Executive
> Director" and "IETF Administration LLC Executive Director" are
> equivalent. Or am I missing your point here?

You are missing my point and perhaps helping to make another
one. First of all, no matter what the LLC Agreement says it can
do, if the IETF Administration LLC actually does business as
[the] "IETF", it creates confusion with the IETF as a technical
standards body and a number of functions that Section 4(b) of
the LLC Agreement explicitly forbids it to change.   It was a
bad idea to refer to the IETF as "ISOC" or vice versa before the
arrangements were changed; it is a bad idea to confuse the IETF
with the IETF Administration LLC now.  I hope you agree.

Second, and more to my point, there are documents scattered
across the Internet, many of them not in the RFC Series or
otherwise within the power of the IETF (or ISOC or the IETF
Administration LLC) that include use of the term "IETF Executive
Director" to refer to the old function, one that is not
completely subsumed by "Managing Director, IETF Secretariat".
Probably that name should never have been used but it made sense
at the time and there is no possible way to undo it.  Given
that, the best way to avoid confusion would have been to choose
some other title for the senior staff person for the IETF
Administration LLC and, in retrospect, every IETF participant or
other member of the community who had a chance to spot that
problem and didn't (myself included) should be ashamed
themselves and probably asking deep questions about how and why
the review process failed).   

However, I understand from Alissa's note that it it too late to
change it now, so I'm looking for ways to mitigate the damage.
One of them is to notice that we (and presumably whatever
documents are out there) rarely, if ever, used "Executive
Director" without putting "IETF" in front of it.  That gives us
an opportunity to develop a discipline of not using "IETF
Executive Director" for the new, LLC-related, position
regardless of what the LLC Directors "can" do and instead use
"Executive Director" only in contexts and with associated
terminology that make the LLC relationship clear.   It may be
that we should go even further: as far as I know, nothing stops
the IETF community and the LLC Board from calling the LLC's
Executive Director anything it likes even if some usages might
require a footnote saying "Formally, the IETF Administration LLC
Executive Director".   Perhaps "IALED" if anyone could figure
out how to pronounce that.   Or "Grand LLC Poo".  Or, in what
would be a historical complement and in-joke typing the current
IETF to its past, perhaps "SteveCoya" :-).

Again, if the Directors of the IETF Administrative LLC wants to
use the title "IETF Executive Director" for this position, I
guess we have dug ourselves in deeply enough that we can't
prevent it.   I would, however, suggest to the Nomcom and other
appointing bodies that anyone who would be that insensitive to
the issues probably should not be a Director.

best,
  john

p.s. the dI-D is in the posting queue, waiting for a WG co-chair
to sign off on posting it.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 15 Nov 2018 16:17:03 -0500

Thank you. I think you are exaggerating the impact and confusion that will
result from using IETF Executive Director as we've chosen to do in this
work.

Joseph Lorenzo Hall

---

From: John C Klensin <[email-masked]>
Date: Thu, 15 Nov 2018 17:54:25 -0500

Perhaps you are right.  I hope you are.  But let's look at costs
and risks.

Costs:

* The LLC does not call itself the IETF or use that as a
business identity unless there are really good and obvious
reasons in a particular case.   Cost: zero

* We avoid calling the LLC senior staff member the "IETF
Executive Director" whatever else we might choose to call her or
him.  Cost: requires a bit of attention until we get into the
right habits but, if adopted now rather than after other habits
have set in, just about zero.

* We check the WG's documents carefully to be sure the right
terminology is being used and, to the extent possible, we also
check other documents that might be affected by the transition.
Cost: higher than I'd like (based especially on my experience
trying to draw this I-D together), but I don't see any way to
avoid doing it.

Now, risks:

* If you are right and I'm exaggerating the impact and
confusion, we've lost little or nothing unless there really are
good reasons for the IETF Administration LLC doing business as
the IETF that I've missed and you haven't mentioned yet.

* If I'm right to be concerned, even partially so, we save
ourselves a lot of aggravation.

Seems clear to me.  YMMD.

   john

p.s. I've been wondering about a small elephant which, whether
in the room or not, has not seemed to be on anyone's radar.  The
IETF (under the auspices of the IAB) has external liaison
relationships with a rather large number of bodies.  Because, in
many cases, those liaisons had to be approved by the other
bodies, there are documents that we do not control (and might
never have seen or entered into our records) that may refer to
us.   Because those other bodies may have wanted a corporate
entity in their documents, some subset of those documents may
specify liaisons with ISOC (with the expectation of an IAB
handoff), not the rather more nebulous IETF or IAB.  Has the IAB
checked those liaison arrangements one at a time to be sure that
they do not need correction?  Or has a careful determination
been made that there is nothing to worry about given that the
LLC is an ISOC subsidiary?  Or is the assumption that this WG
will sort all of that out as part of the transition process?

Just wondering.

--On Thursday, November 15, 2018 16:17 -0500 Joseph Lorenzo Hall
<[email-masked]> wrote:

> Thank you. I think you are exaggerating the impact and
> confusion that will result from using IETF Executive Director
> as we've chosen to do in this work.
> 
>> --On Thursday, November 15, 2018 15:31 -0500 Joseph Lorenzo
>> Hall <[email-masked]> wrote:
>> 
>> >> * As a further issue with the Executive Director title,
>> >> there is no longer any such thing as an "IETF Executive
>> >> Director" unless one applies a creative reading to the
>> >> "may do business as" text in Section 1(b) of the LLC
>> >> Agreement.   IANAL, so have no opinion about whether such
>> >> a reading would be permissible but it would certainly
>> >> create more confusion about any boundaries between the LLC
>> >> and the IETF.  So we should probably get rid of any
>> >> references to "IETF Executive Director" when they refer to
>> >> the "Executive Director of the IETF Administration LLC".
>> >> That will require some further updates to other documents;
>> >> the current I-D certainly does not have it right and is
>> >> not complete.   This is also partially covered by the rant
>> >> referred to above.
>> 
>> > Yes, the IETF Adminstration LLC does business as "IETF", if
>> > I recall correctly, and so the two phrases "IETF Executive
>> > Director" and "IETF Administration LLC Executive Director"
>> > are equivalent. Or am I missing your point here?
>> 
>> one. First of all, no matter what the LLC Agreement says it
>> can do, if the IETF Administration LLC actually does business
>> as [the] "IETF", it creates confusion with the IETF as a
>> technical standards body and a number of functions that
>> Section 4(b) of the LLC Agreement explicitly forbids it to
>> change.   It was a bad idea to refer to the IETF as "ISOC" or
>> vice versa before the arrangements were changed; it is a bad
>> idea to confuse the IETF with the IETF Administration LLC
>> now.  I hope you agree.
>> 
>> Administration LLC) that include use of the term "IETF
>> Executive Director" to refer to the old function, one that is
>> not completely subsumed by "Managing Director, IETF
>> Secretariat". Probably that name should never have been used
>> but it made sense at the time and there is no possible way to
>> undo it.  Given that, the best way to avoid confusion would
>> have been to choose some other title for the senior staff
>> person for the IETF Administration LLC and, in retrospect,
>> every IETF participant or other member of the community who
>> had a chance to spot that problem and didn't (myself
>> included) should be ashamed themselves and probably asking
>> deep questions about how and why the review process failed).
>> 
>> However, I understand from Alissa's note that it it too late
>> to change it now, so I'm looking for ways to mitigate the
>> damage. One of them is to notice that we (and presumably
>> whatever documents are out there) rarely, if ever, used
>> "Executive Director" without putting "IETF" in front of it.
>> That gives us an opportunity to develop a discipline of not
>> using "IETF Executive Director" for the new, LLC-related,
>> position regardless of what the LLC Directors "can" do and
>> instead use "Executive Director" only in contexts and with
>> associated terminology that make the LLC relationship clear.
>> It may be that we should go even further: as far as I know,
>> nothing stops the IETF community and the LLC Board from
>> calling the LLC's Executive Director anything it likes even
>> if some usages might require a footnote saying "Formally, the
>> IETF Administration LLC Executive Director".   Perhaps
>> "IALED" if anyone could figure out how to pronounce that.
>> Or "Grand LLC Poo".  Or, in what would be a historical
>> complement and in-joke typing the current IETF to its past,
>> perhaps "SteveCoya" :-).
>> 
>> Again, if the Directors of the IETF Administrative LLC wants
>> to use the title "IETF Executive Director" for this position,
>> I guess we have dug ourselves in deeply enough that we can't
>> prevent it.   I would, however, suggest to the Nomcom and
>> other appointing bodies that anyone who would be that
>> insensitive to the issues probably should not be a Director.
>> 
>> best,
>>   john
>> 
>> p.s. the dI-D is in the posting queue, waiting for a WG
>> co-chair to sign off on posting it.
>> 
>> 
>> 
>> --
> 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, 16 Nov 2018 12:01:23 +1300

> result from using IETF Executive Director as we've chosen to do in this

Regardless of who is right about that, it seems to me that we need to
be crystal clear in our current and future use of any such terms; we
can't undo the past or feed existing documents into the Memory Hole,
so that part of the confusion is out of our hands anyway.

(As for the LLC "doing business as" the IETF, I think that is fair
enough, for interfacing to hotels, sponsors etc. But definitely not for
interaction with other SDOs or any matters related to the standards
process - so that restriction needs to be part of the LLC's DNA.)

   Brian

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 15 Nov 2018 18:03:23 -0500

+1

---

From: John C Klensin <[email-masked]>
Date: Thu, 15 Nov 2018 18:41:15 -0500

--On Friday, November 16, 2018 12:01 +1300 Brian E Carpenter
<[email-masked]> wrote:

>...
> (As for the LLC "doing business as" the IETF, I think that is
> fair enough, for interfacing to hotels, sponsors etc. But
> definitely not for interaction with other SDOs or any matters
> related to the standards process - so that restriction needs
> to be part of the LLC's DNA.)

With that qualification, I don't have any problem with "doing
business as".  I think that is completely consistent with what I
described as "really good and obvious reasons in a particular
case".  Brian's comment about the restriction and the LLC's DNA
captures what I was trying to get at much better than I did.
Anything that would create the impression, especially for
outsiders, that the LLC had authority over standards, was the
final authority for standards [1], or otherwise was the tail
wagging the IETF dog  would be a really bad idea.

    john

[1] Might be worth remembering that the final standards approval
authority in some other SDOs actually is a panel or other
collection of people who are not intimately involved in the
standards development process or accountable to those who are.
So, for some outsiders who find that model familiar, it would
not be a huge leap to inferring that the LLC Directors are the
standards-approvers.

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 19 Nov 2018 16:49:48 -0500

> On Nov 15, 2018, at 6:41 PM, John C Klensin <[email-masked]> wrote:
> 
> 
> 
> case”.  

The LLC has registered to be able to do business as “IETF,” “Internet Engineering Task Force,” and “IETF LLC,” for the reasons Brian stated. 

Alissa

> Brian's comment about the restriction and the LLC's DNA

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 19 Nov 2018 17:14:26 -0500

I think the fact of the matter is that we created the LLC in response to concerns about lack of clarity about representation and authority [1], especially vis a vis external parties. Anyone who is participating in the IETF may read the process RFCs, where we can go into extensive detail about defining terms and titles however we wish. Parties external to the IETF — entities with which the LLC contracts, or from which it raises money, or employers who might hire its staff in the future once they’re done working at the LLC — are mostly never going to read them, and in those situations the terms/titles provide the most value by signaling what external parties expect them to singal. Expecting the executive director of the LLC to use the title "IETF Executive Director” seems appropriate and consistent with the goals in [1].

More below.

[1] https://tools.ietf.org/html/draft-haberman-iasa20dt-recs-02#section-3.1.2

> On Nov 15, 2018, at 5:54 PM, John C Klensin <[email-masked]> wrote:
> 

ISOC’s existing memberships in SDOs are explicitly left alone in the LLC agreement section 4(b).

Alissa

---

From: Glenn Deen <[email-masked]>
Date: Mon, 19 Nov 2018 17:43:39 -0800

John,

I’m not convinced that things are as complicated or dire as your notes have alluded to.  People, orgs and entities are not mindless automatons, they can update their understanding of terms and relabeling of roles and names, and the IETF LLC is not an independent entity we need to come to terms with.  Please see below in line..

> On Nov 15, 2018, at 2:54 PM, John C Klensin <[email-masked]> wrote:
> 

The LLC is us, it is part of the IETF, and not a separate thing that is operating independently or at crossed purposes with the IETF.      Yes, the role of LLC board and staff is restricted to administration yet they are still part of the ietf and can and should act to support the Ietf’s work and mission.    The parts of the IETF - the community, the IAB, the IESG, the IRTF Trust, and the LLC each have their roles and each support the IETF mission in their duties and responsibilities. 

In other words, the LLC works hand in hand with the other parts of the IETF and it is a legal entity that is capable of entering into contracts and agreements on behalf of the entirety of the IETF.  That’s an important and useful function that the LLC provides to the IETF.  If the IAB or IESG needs an entity to legally contract for them, the LLC is that entity except on matters that fit better with the IETF Trust.

> have set in, just about zero.

Why?  What’s the material impact of using the term ?

> the IETF that I've missed and you haven't mentioned yet.

Can you give some hard data here so we can discuss the details?  Again, the IETF LLC is part of the IETF by design and not a separate competing entity.  It is us.  So what are the material issues and risks to manage?

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 20 Nov 2018 19:53:44 +0000

+1

On 11/19/18, 5:14 PM, "iasa20 on behalf of Alissa Cooper" <[email-masked] on behalf of [email-masked]> wrote:

    More below.

    
    
    Alissa

---

From: Bob Hinden <[email-masked]>
Date: Tue, 20 Nov 2018 13:46:32 -0800

John,

A few comments on draft-ietf-iasa2-consolidated-upd-00 are below.

Thanks for pulling this together, it is useful and helpful.

Bob

————

>  1
> .  Introduction
> 
>    In 2018, the IETF began the transition to a new administrative
>    structure, and updated its IETF Administrative Support Activity
>    (IASA) to a new "IASA 2.0" structure [RFC-Struct].  Key IASA 2.0
>    changes have been specified in a series of documents, including
>    changes to the IETF Trust [RFC-trust-update], the rationale for it
>    [RFC-trust-rationale], a new defining document for the IETF
>    Administration LLC [LLC-Agreement] (informally called the "IETF LLC"
>    or just "the LLC" in places in this document and elsewhere) and

From [RFC-Struct], I think the correct name of the LLC is:

   IETF Administration Limited Liability Company

This shows up here and a few places later in the document as well.

> 2.  Remove Text About the Connection Between the IAOC and IETF Trust
> 
>    Some documents that discuss the IETF Trust or its relationship to the
>    community describe it, or the Trustees, in relation to the IAOC.
>    That connection must be eliminated to reflect the new IASA 2.0
>    structure.

Might be good to include a reference here to the new IETF Trust documents.  They are cited earlier.

> 4.  Where Appropriate, Replacement of the IETF Executive Director
>     position with the Managing Director, IETF Secretariat
> 
>    Under the IASA 2.0 structure, most of the responsibilities of the
>    former position of IETF Executive Director been assigned to a new
>    position (or at least title) of Managing Director of the IETF
>    Secretariat.

I don’t think this is correct.  As far as I can tell, the position is new (perhaps evolved from the IAD position), that is, it is not taking on the responsibilities of the position of the same name now called the Managing Director of the IETF Secretariat.

The also applies to the CREF3 paragraph that follows this paragraph.

> An "Executive Director" title is now associated with
>    different, and largely new, responsibilities as an Officer of the
>    IETF Administration LLC.  These changes are described in the
>    description of the new structural arrangements [
>    RFC-Struct].

I don’t see anywhere in [RFC_Struct] where the Executive Director is called an “Officer” of the IETF LLC.  Suggest removing it.

BTW, I am fine with calling the LLC position the “IETF Executive Director” as you cited me in:

>    [[CREF5: Note in Draft: Bob Hinden's note of November 10, 2018 11:37
>    +0900 indicates that RFC4844 should continue to reference the IETF
>    Executive Director.]]

---

From: John C Klensin <[email-masked]>
Date: Wed, 21 Nov 2018 04:09:25 -0500

Glenn and Alissa (and probably Jason and Joseph),

Let's take a half-step back and examine what I think is a
difference in perspective.  I don't believe I ever said "dire".
I don't believe the situation is anywhere near dire.  On the
other hand, the rationale that has been giving for going the LLC
route at all is also a good deal short of "dire".  That doesn't
mean I think it shouldn't be done -- the balance of advantages
against disadvantages and conclusions by the four of you and
others who have studied this carefully and through the lens of
far more legal expertise than most of us would claim seems to
argue for doing it and I'm not questioning that conclusion.

Another part of the issue I'm seeing, which should not be a
surprise, much less dire, is that the people who have been
deeply immersed in planning this change, including the drafting
and review of the IETF Administration LLC agreement, are much
more familiar with that document, and probably a collection of
other documents that exist in drafts at various stages of
completion, than the typical IETF participant --even the typical
IETF participant who is somewhat interested but not deeply dug
in.

I'm also fairly certain that, were we starting from scratch at
this point, i.e., if IASA 1.0 had never happened, we wouldn't be
having this discussion because, if the structure and terminology
were being put in place for the first time, it would be just
fine.  That is especially true for the head staff position of
the LLC for which, with no history, "Executive Director" would
be entirely reasonable.   Given the history, while I think the
decision to [re]use that title was unfortunately, as I have said
before, I completely accept Alissa's explanation as to why it is
too late to change that now.

I am raising only three issues, none of which seem complicated
to me.  In the order in which I noticed:

(1) The IASA 2.0 WG, for whatever reason, isn't managing to get
careful reviews by IETF participants who did not write or
actively participate in the drafting of that WG's documents.
As a consequence, errors and omissions are persisting in
documents that have been identified as passing WG LC.   I don't
see this as a matter of blame, but I believe we should (and
would) be concerned about the products with as low a level of
involvement by people other than authors and WG leadership as
that one seems to be showing (even after the issue was raised).
That concern about review would be less serious if the WG's
focus and task were narrowly constrained, but...

(2) The WG's decision to reissue fundamental IETF process
documents is problematic even (or especially) given the charter
provision that it is to confine itself to IASA 2.0 and
transition issues and to not make process changes.  The
potential problems increase if there are an insufficient number
of  independent reviews looking for inadvertent changes or if
the relevant documents should be revised for other reasons
(e.g., errata, changes in practices over the years, etc.) but
are being reissued without addressing those issues.  The
decision to reissue/ replace those process documents puts the WG
into a nearly-untenable situation: either the documents are
updated to reflect those other changes (violating the promises
the charter made to the community and, more important, the
common-sense principle that we should not make fundamental
process changes without much relatively extensive community
involvement) or those other potential changes are ignored
(leaving the new process documents in an uncertain state with
regard to errata and updates --whether published or merely oral
tradition and practice-- that applied to the original versions).
I can imagine two solutions, one of which would be to replace
the original documents with new ones that make the needed IASA
2.0 changes and enumerate all of the other issues that should be
addressed (with references and their status where appropriate)
without taking a position on any of them that are not settled
issues.  That impresses me as very difficult, but at least
wouldn't have the WG revising process models.  The other is to
narrowly update whatever sections and statements need to be
changed without replacing the base procedural documents, noting
that is exactly what we did with even earlier documents when
IASA 1.0 and the IETF Trust were first created.   

I didn't feel it was reasonable to complain about the situation
without being willing to do a significant amount of the work and
that is what draft-ietf-iasa2-consolidated-upd is about.  I note
that, except for Bob Hinden if he belongs in that category, none
of the recent comments from those most responsible for the
decision to move forward with the LLC plan have actually
addressed that I-D.

(3) Confusion about the name and possible relationship changes.
As a general principle, when a name is used for some years for
one thing and then roles and definitions change, it is better to
retire the name and use something else to describe the new and
old roles.  We didn't do that in this case but, instead,
repurposed a previously-used name.  There may have been
perfectly good reasons for that -- again, I accept the
conclusion that it is too late to make a change so don't see the
decision itself as worth revisiting.  However, because people
are easily confused, it is worthwhile to explain that the new
name(s) and old names with new definitions are being used what
they mean and to do so (for at least some years) and to do so
early and often.  Saying "well, it is defined in XYZ" is not
sufficient unless there is some way to ensure that everyone who
is relevant and might be affected has read, or will soon read,
XYZ and remember what it says.  Maybe I'm exaggerating this, but
I believe that many IETF participants have not read and
understood RFC2026 (or 2418 or 7437 and their various updates,
at least within recent years.  "Anyone who is participating in
the IETF may read the process RFCs, where we can go into
extensive detail about defining terms and titles however we
wish" is not sufficient unless we actually supply that detail...
and have a reasonable expectation that people will do that
reading.  We may not be able to control the latter, but should
at least ensure that the details are written down and written
down in enough places that we don't need to have the expectation
that people will read and remember every document, especially
documents not in the RFC Series.   There is also a possibility
of definitional confusion when terminology and definitions have
not changed but the context has: if there is a reasonable
possibility that responsibility for something older may have
changed, we should be explicit about it even when it has not.

Let me borrow from Alissa's note to illustrate an example of
this, an example made more acute when it is hard to find the
relevant document and/or it may be subject to alternate
interpretations.   In response to my concern about liaisons
involving organizations who think their linkage it to the IETF
but whose documents mention the ISOC because, at the time, it
was the IETF's legal/ corporate home, she wrote "ISOC's existing
memberships in SDOs are explicitly left alone in the LLC
agreement section 4(b).".   So, first, let's go find that
section.   If one goes to www.ietf.org, clicks on "search", and
enters "LLC agreement", one finds one reference, for "IETF
Administration LLC".  That leads to a page
(https://www.ietf.org/llc/ ) which doesn't have section numbers,
much less a section 4(b).  To find that section, one needs to
know (or guess) that it is a "Legal document" and then click on
"LLC Agreement" most of the way down the page.  If, having
figured that one, one downloads and opens the PDF document and
goes to Section 4(b).   It does not contain the word "liaison".
If one reads the first two sentences:

	"The purpose of the Company is to provide a corporate
	legal framework for facilitating current and future
	activities related to the Internet Engineering Task
	Force, the Internet Architecture Board (IAB), and the
	Internet Research Task Force (IRTF). The intent is that
	legal responsibility for all IETF-related activities
	under the corporate umbrella of the Member as of the
	Effective Date will transfer to the Company."

a reasonable person could read that and conclude that liaisons
(either those previously designated as involving ISOC or all of
them) are intended to move to the LLC.  They are certainly part
of the corporate umbrella of the Member (ISOC), not just because
ISOC is explicitly part of that role but because, prior to the
LLC's being established, the IETF and everything it did was
under ISOC's corporate umbrella.  One could interpret the
subsequent sentences:

	"Except as minimally necessary to provide appropriate
	administrative and legal support ... formation of the
	Company is not intended to change anything related to
	the oversight or steering of the standards process as
	currently conducted by ... or Member's memberships in or
	support of other organizations."

Whether that excludes liaisons and leaves them with ISOC or not
depends on whether one interprets liaisons as part of "oversight
or steering of the standards process" (they are almost certainly
not) or ISOC's "memberships in or support of other
organizations".  For the latter, we (whatever that means)
certainly do not become members of organizations to which we
establish liaisons and it would be at least as reasonable to
claim that those liaisons support the IETF and its work as as to
claim they they (and the IETF) are supporting the other body.   

Again, too late to change, but certainly something we should
explain better (and in readily-accessible places) than pointing
to that section and moving on.  This also illustrates part of
why (1) above is important: those who wrote, or were heavily
involved in drafting, the LLC Legal Agreement know what they
intended it to mean.   Reviewing it carefully enough to know
whether it actually says those things, and and says them
unambigously, requires fresh sets of eyes, ideally eyes that are
at least a little bit paranoid about alternative interpretations.

One final pair of comments, after which I'm going to hope that
I've made my point (rather than having to go back through things
I've written more than once already)...

--On Monday, November 19, 2018 17:43 -0800 Glenn Deen
<[email-masked]> wrote:

>...
> People, orgs and entities are not
> mindless automatons, they can update their understanding of
> terms and relabeling of roles and names, and the IETF LLC is
> not an independent entity we need to come to terms with.

However, while we were trying to sort out questions of appeals,
there was significant discussion of the fact that the IETF
cannot actually tell the LLC's Directors  what to do except by
recalling them (or replacing them during a normal Nomcom cycle)
and replacing them with people who are more responsive.  I'm not
concerned about gross malfeasance here, but we should still
remember that the contemporary IETF originated because the key
oversight body got seriously out of touch with, and unresponsive
to, the community... not believe its members were evil but
because perspectives and intentions drifted apart.   U hope we
never see the Directors say something equivalent to "if you in
the IETF community knew what we know and understood what we
understand, you would agree with our decisions" but note that
the IAOC (which _was_ subject to binding appeals) came fairly
close to that on occasion.   Being careful about intentions at
this point is just prudent and good protection against
misunderstandings.

> The LLC is us, it is part of the IETF, and not a separate
> thing that is operating independently or at crossed purposes
> with the IETF.      Yes, the role of LLC board and staff is
> restricted to administration yet they are still part of the
> ietf and can and should act to support the Ietf's work and
> mission. 

You have just expressed a principle that we can all hope for and
reasonably expect.   But it is not a requirement.  The LLC
actually is a "separate thing that is operating independently".
The Directors are trusted by the IETF to do the right thing but
are independent of it by both the provisions of the legal
agreement and, we've been told, by Delaware law.   That creates
certain (I hope very low-likelihood) risks that are unavoidable
that that I/we have to believe are worth it.  But, by being very
clear, we can at least avoid misunderstandings about
expectations.  The LLC Legal Agreement, in combination with the
work of the WG so far, does not, IMO, meet that standard.  YMMD,
of course, but, if it does, please try to read the paragraphs
quoted above and see if you are unambiguously convinced, without
engaging in "I know what that is supposed to mean" analysis or
wishful thinking, where it leaves liaisons... and then convince
yourself that is the only possible example.

best,
    john

---

From: John C Klensin <[email-masked]>
Date: Wed, 21 Nov 2018 04:52:52 -0500

> Thanks for pulling this together, it is useful and helpful.

thanks.  Comments inline below.

>>  1
>> .  Introduction
>> 
>>    In 2018, the IETF began the transition to a new
>>    administrative structure, and updated its IETF
>>    Administrative Support Activity (IASA) to a new "IASA 2.0"
>>    structure [RFC-Struct].  Key IASA 2.0 changes have been
>>    specified in a series of documents, including changes to
>>    the IETF Trust [RFC-trust-update], the rationale for it
>>    Administration LLC [LLC-Agreement] (informally called the
>>    "IETF LLC" or just "the LLC" in places in this document
>>    and elsewhere) and
> 
> 

I think the binding/ formal name is "IETF Administration LLC",
which is painfully clear in Section 1(a) of the LLC Legal
Agreement (for convenience,
https://www.ietf.org/documents/180/IETF-LLC-Agreement.pdf ).  If
[RFC-Struct] disagrees with that, it is wrong and should be
corrected (and I will keep muttering about lack of sufficient
careful review).  It may be worth remembering, as Alissa has
reminded us in another context, that the LLC legal agreement is
the on things in this discussion that is cast in stone;
everything else, AFAIK, is under the control of the WG and
subsequent IETT LC review.

>>    Some documents that discuss the IETF Trust or its
>>    relationship to the community describe it, or the
>>    Trustees, in relation to the IAOC. That connection must be
>>    eliminated to reflect the new IASA 2.0 structure.
> 

Will fix.   As a matter of habit (worked out over the years with
the RFC Editor), I tend to not cite a document again that has
already been cited unless that is necessary.  I agree with you
that this comes close to necessary but wonder whether the new
documents, the old ones, or both, should be referenced.  The
first sentence would seem to call for the older ones.

>> 4.  Where Appropriate, Replacement of the IETF Executive
>> Director position with the Managing Director, IETF Secretariat
>> 
>>    Under the IASA 2.0 structure, most of the responsibilities
>>    of the former position of IETF Executive Director been
>>    assigned to a new position (or at least title) of Managing
>>    Director of the IETF Secretariat.

> I don't think this is correct.  As far as I can tell, the
> position is new (perhaps evolved from the IAD position), that
> is, it is not taking on the responsibilities of the position
> of the same name now called the Managing Director of the IETF
> Secretariat.

Interesting.  Now I'm really confused (and several others who
have explained this to me in recent weeks may be too).   Going
back to when we started using the "IETF Executive Director"
title for Steve Coya, it has belonged to the person who actually
manages the Secretariat and who is an employee of the
organization that employs the Secretariat.  In the world prior
to the LLC, the title went to someone in the employ of AMS.   A
title like "Managing Director of the IETF Secretariat" actually
seems more appropriate to that position, with or without the
LLC, but there were advantages of having a slightly more
IETF-linked and authoritative-sounding title.  By contrast, the
former IAD position was staff to and (with ISOC as an
intermediary) effectively an employee of IASA 1.0 and not a
contracted body.  It may be relevant that Portia, the last
interim IAD, is identified at https://www.ietf.org/llc/ as
"current Interim IETF Executive Director" (the new title) so it
is natural to assume that most IAD functions went there.

>>    different, and largely new, responsibilities as an Officer
>>    of the IETF Administration LLC.  These changes are
>>    described in the description of the new structural
>>    arrangements [ RFC-Struct].
> 
> 
> I don't see anywhere in [RFC_Struct] where the Executive
> Director is called an "Officer" of the IETF LLC.  Suggest
> removing it.

LLC Agreement (Trust Legal Agreement,
https://www.ietf.org/documents/180/IETF-LLC-Agreement.pdf )
Section 5(c), 

	"Executive Director; Staff. The Board will hire and
	supervise an Executive Director, who will be deemed an
	Officer of the Company."

Again, if [RFC-Struct] is inconsistent with that agreement, it
must be fixed or we really have confusion.

> BTW, I am fine with calling the LLC position the "IETF
> Executive Director" as you cited me in:
> 
>>    [[CREF5: Note in Draft: Bob Hinden's note of November 10,
>>    2018 11:37 +0900 indicates that RFC4844 should continue to
>>    reference the IETF Executive Director.]]

Having now gone back and looked at 4844 itself (not just your
draft revision), I note that 4844 does not mention the IETF
Executive Director.   It does mention, in Section 3.3, the IAD
(as "chief actor for the IASA").  So, your use of the "Executive
Director" title is definitely correct.  It is also consistent
with the comments above about the [new] IETF Executive Director
title and the former IAD one.  And it suggests that the note
should be removed and replaced by another subjection that
replaces the IAF title with the IETF ExecCir one for selected
documents, notably 4844 Section 3.3.   Assuming BCP 101 will
eventually be bound to [RFC-Struct] (aka
[I-D.ietf-iasa2-struct]), it may not be necessary to change the
first paragraph of 4844, but that could be done in the same way
if the WG concluded it were desirable.

best,
    john

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 21 Nov 2018 07:46:40 -0500

We'll be making some big changes to -struct over the coming week to make it
actually a 4071bis document, so all of this is helpful and will be a part
of that set of edits. Thank you.

We should have something to the WG next week and you can imagine we'd
really want careful review of that document! Thanks, Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 21 Nov 2018 09:28:22 -0500

> is natural to assume that most IAD functions went there.

I believe it is correct to suggest that most of the responsibilities,
and some new ones besides, are now IETF ED responsibilities that used
to be IAD responsibilities.  (I think many of us recognized even when
reworking the titles was first mooted that there could be some
confusion arising from this over the period of the transition, but I
at least was persuaded that the long-term benefits in terms of clarity
outweighed the disadvantages in the sort term.  Obviously, others may
differ on this point, but as John has now noted several times it
doesn't really matter since we now have a legal structure that depends
on the new usage of the term.)

On the point of "effectively an employee of IASA 1.0", I want to
emphasise once again that this was in fact one of the very serious
problems with the former structure.  For reasons of employment law,
that structure simply couldn't be sustained in a way that the old
BCP101 imagined, and we ran into practical difficulties as a result.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Wed, 21 Nov 2018 09:37:14 -0500

--On Wednesday, November 21, 2018 07:46 -0500 Joseph Lorenzo
Hall <[email-masked]> wrote:

> We'll be making some big changes to -struct over the coming
> week to make it actually a 4071bis document, so all of this is
> helpful and will be a part of that set of edits. Thank you.
> 
> We should have something to the WG next week and you can
> imagine we'd really want careful review of that document!
> Thanks, Joe

Joe,

Thanks.  Good to know -- getting -struct completely sorted out
will be a huge help with all of this,  Please also pay careful
attention to the paragraph at the end of my note below about the
issues raised by 4844 / proto-4844bis (despite my typos --
"subjection" -> "subsection" and "IAF" -> "IAD" in case that was
not clear).  It seems to me that the paragraph there that
explains the IASA / IASA2 structure is just looking for trouble
and should mostly be stripped out and replaced with the BCB101
reference that is already there (this is a flaw in 4844 --
understandable at the time it was written, but...).  

In case it has not been clear, I think 4071 (and 4371 and 7691)
are documents that the WG should definitely replace, creating a
unified BCP101.  My concerns about undesirable replacements are
about documents that are only peripherally affected.

best,
   john

>> >>    Administrative Support Activity (IASA) to a new "IASA
>> >>    2.0" structure [RFC-Struct].  Key IASA 2.0 changes have
>> >>    been specified in a series of documents, including
>> >>    changes to the IETF Trust [RFC-trust-update], the
>> >>    rationale for it [RFC-trust-rationale], a new defining
>> >>    document for the IETF Administration LLC
>> >>    [LLC-Agreement] (informally called the "IETF LLC" or
>> >>    just "the LLC" in places in this document and
>> >>    elsewhere) and
>> > 
>> > 
>> https://www.ietf.org/documents/180/IETF-LLC-Agreement.pdf ).
>> If [RFC-Struct] disagrees with that, it is wrong and should be
>> reminded us in another context, that the LLC legal agreement
>> is the on things in this discussion that is cast in stone;
>> >>    Trustees, in relation to the IAOC. That connection must
>> >>    be eliminated to reflect the new IASA 2.0 structure.
>> > 
>> Will fix.   As a matter of habit (worked out over the years
>> with the RFC Editor), I tend to not cite a document again
>> that has already been cited unless that is necessary.  I
>> agree with you that this comes close to necessary but wonder
>> whether the new documents, the old ones, or both, should be
>> referenced.  The first sentence would seem to call for the
>> older ones.
>> 
>> 
>> >>    Under the IASA 2.0 structure, most of the
>> >>    responsibilities of the former position of IETF
>> >>    Executive Director been assigned to a new position (or
>> >>    at least title) of Managing Director of the IETF
>> >>    Secretariat.
>> 
>> > position is new (perhaps evolved from the IAD position),
>> > that is, it is not taking on the responsibilities of the
>> > position of the same name now called the Managing Director
>> > of the IETF Secretariat.
>> 
>> title for Steve Coya, it has belonged to the person who
>> actually manages the Secretariat and who is an employee of the
>> to the LLC, the title went to someone in the employ of AMS.
>> A title like "Managing Director of the IETF Secretariat"
>> actually seems more appropriate to that position, with or
>> without the LLC, but there were advantages of having a
>> slightly more IETF-linked and authoritative-sounding title.
>> By contrast, the former IAD position was staff to and (with
>> ISOC as an intermediary) effectively an employee of IASA 1.0
>> and not a contracted body.  It may be relevant that Portia,
>> the last interim IAD, is identified at
>> https://www.ietf.org/llc/ as "current Interim IETF Executive
>> Director" (the new title) so it is natural to assume that
>> most IAD functions went there.
>> 
>> >>    different, and largely new, responsibilities as an
>> >>    Officer of the IETF Administration LLC.  These changes
>> >>    are described in the description of the new structural
>> >>    [[CREF5: Note in Draft: Bob Hinden's note of November
>> >>    10, 2018 11:37 +0900 indicates that RFC4844 should
>> >>    continue to reference the IETF Executive Director.]]
>> 
>> (as "chief actor for the IASA").  So, your use of the
>> "Executive Director" title is definitely correct.  It is also
>> consistent with the comments above about the [new] IETF
>> Executive Director title and the former IAD one.  And it
>> suggests that the note should be removed and replaced by
>> another subjection that replaces the IAF title with the IETF
>> ExecCir one for selected documents, notably 4844 Section 3.3.
>> Assuming BCP 101 will eventually be bound to [RFC-Struct] (aka
>> [I-D.ietf-iasa2-struct]), it may not be necessary to change
>> the first paragraph of 4844, but that could be done in the
>> same way if the WG concluded it were desirable.
>> 
>> best,
>>     john
>> 
>> 
>>

---

From: Bob Hinden <[email-masked]>
Date: Wed, 21 Nov 2018 13:30:24 -0800

John,

inline.

Bob

> On Nov 21, 2018, at 1:52 AM, John C Klensin <[email-masked]> wrote:
> 
> 
> 

I have been using [RFC-Struct] as the authoritative source for information.   Having the two be different is a problem.

Note, I am troubled that this process is moving forward with out an IETF last call on [RFC-Struct] to determine IETF consensus.  This is an issue to me.

> first sentence would seem to call for the older ones.

Thanks.  It’s not critical, but would make the text clearer in my view.

> have explained this to me in recent weeks may be too).

:-)

> Going

I think the only thing about the position that reports to the IESG (IETF Executive Director -> Managing Director of the IETF Secretariat) that has changed, is the title of the position.  The role stays the same.

> must be fixed or we really have confusion.

Yes, as I also noted above.

> if the WG concluded it were desirable.

Sounds good.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 21 Nov 2018 16:40:48 -0500

On Wed, Nov 21, 2018 at 4:30 PM Bob Hinden <[email-masked]> wrote:

> I have been using [RFC-Struct] as the authoritative source for
> information.   Having the two be different is a problem.
>
>
They won't be different soon, stay tuned.

> Note, I am troubled that this process is moving forward with out an IETF
> last call on [RFC-Struct] to determine IETF consensus.  This is an issue to
> me.

I had thought we had made this clear? -struct couldn't go forward after
WGLC as it needed to be a more proper 4071bis and less of a draft
documenting the work of the IASA2 WG. Jason and I are currently making
these edits and will have a new draft of -struct which we'll start
referring to as 4071bis soon. That will need WG discussion and another WGLC
before going forward to IETF LC, etc.

best, Joe

---

From: John C Klensin <[email-masked]>
Date: Wed, 21 Nov 2018 16:48:19 -0500

--On Wednesday, November 21, 2018 16:40 -0500 Joseph Lorenzo
Hall <[email-masked]> wrote:

>...
> I had thought we had made this clear? -struct couldn't go
> forward after WGLC as it needed to be a more proper 4071bis
> and less of a draft documenting the work of the IASA2 WG.
> Jason and I are currently making these edits and will have a
> new draft of -struct which we'll start referring to as 4071bis
> soon. That will need WG discussion and another WGLC before
> going forward to IETF LC, etc.

Joe,

I think it is clear -- now -- the problem is that other
documents, including but certainly not limited to Bob's work--
have been depending on -struct, in its current form, for
definitions and context.   I think that means (i) we need the
version of -struct/ 4071bis to which you refer but then (ii) we
are going to need to reopen and (to the extent to which there
has been review) re-review of almost everything else the WG has
done, especially (but not limited to) anything that references
-struct either normatively or informatively.  IMO, that
strengthens the argument for a consolidated update piece rather
than a large collection of documents that replace earlier ones
because one of the main arguments for sticking with the latter
has been that they are done or nearly done which, apparently,
they aren't any more :-(

  best,
     john

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Nov 2018 10:56:57 +1300

On one point:
On 2018-11-22 10:30, Bob Hinden wrote:
...
> I think the only thing about the position that reports to the IESG (IETF Executive Director -> Managing Director of the IETF Secretariat) that has changed, is the title of the position.  The role s…

Which is exactly why I've been banging on about the need to add
"Updates:" for the ancient usages of the term "IETF Executive Director".
It's pretty much trivial, given a folder containing all RFCs and
grep "IETF Executive Director" rfc*.txt

(There's just the fiddly issue of whether to bother for RFCs that
have been obsoleted or made Historic, or for cases like RFC2026
where the relevant text has been superseded; but too much
clarification is unlikely to hurt.)

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Wed, 21 Nov 2018 14:26:38 -0800

Joe,

> On Nov 21, 2018, at 1:40 PM, Joseph Lorenzo Hall <[email-masked]> wrote:
> 
> I had thought we had made this clear? -struct couldn't go forward after WGLC as it needed to be a more proper 4071bis and less of a draft documenting the work of the IASA2 WG. Jason and I are currently making these edits and will have a new draft of -struct which we'll start referring to as 4071bis soon. That will need WG discussion and another WGLC before going forward to IETF LC, etc.

Yes, I understood that.  The issue I have is that we have created a new legal entity with out having a finalized document that describes it.  As far as I can tell, we have not even had an IETF last call, nor an IETF consensus to proceed with it’s implementation.

This seems odd to me.

Bob

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 26 Nov 2018 10:03:42 -0500

Hi John,

I wanted to pick up on your question about liaisons:

> On Nov 21, 2018, at 4:09 AM, John C Klensin <[email-masked]> wrote:
> 
> agreement section 4(b).”.   

...

> One could interpret the subsequent sentences:
> 

My point in citing 4(b) of the LLC agreement was that we explicitly chose not to make any changes in cases where other organizations have established their relationships with us via ISOC (e.g., ISO, ITU-T). We actually decided this at charter time <https://datatracker.ietf.org/wg/iasa2/about/>. So I don’t see why other organizations’ views of their liaison relationships with us would be treated any differently than those where we know the liaison activity occurs as a function of ISOC’s membership in the organization; if other organizations have it written down somewhere unbeknowst to us that their liaison activity is with ISOC, the creation of the LLC doesn’t change that.

Thanks,
Alissa

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 27 Nov 2018 10:50:35 +0200

On Mon, Nov 26, 2018 at 5:03 PM Alissa Cooper <[email-masked]> wrote:

> My point in citing 4(b) of the LLC agreement was that we explicitly chose
> not to make any changes in cases where other organizations have established
> their relationships with us via ISOC (e.g., ISO, ITU-T). We actually
> decided this at charter time <https://datatracker.ietf.org/wg/iasa2/about/>.
> So I don’t see why other organizations’ views of their liaison
> relationships with us would be treated any differently than those where we
> know the liaison activity occurs as a function of ISOC’s membership in the
> organization; if other organizations have it written down somewhere
> unbeknowst to us that their liaison activity is with ISOC, the creation of
> the LLC doesn’t change that.
>

IMHO, the administration work is different from technology work among
IETF WGs RFCs/efforts, as known new-rules/changes/recommendations may
become good or bad per maker/user. Making technologies or
standards are relationships among computer-organisations for the best of
users first then management, but making admn-procedures
are relationships among human-organisations (human-orgs are more
complicated or more dynamic) for the best of management first then users.
our WG doesn't consider changes within your mentioned cases, but could
we look-into/discuss possible future directions, or now/future
recommendations?

AB