Subject: [Rfced-future] Moving forward: Please state your preference

From: Eliot Lear <[email-masked]>
Date: Fri, 18 Sep 2020 17:55:22 +0200

Hello everyone,

“When you come to a fork in the road, take it.”
— Yogi Bera

The chairs have had an opportunity to discuss the last interim.  We note that some people liked the comparison chart, as a means to highlight both similarities and differences.   We know that some people would very much like to have seen a draft adopted, while others were not ready to move forward.  Several people would instead like to go issue by issue and resolve those issues before adopting a draft.  The chairs will leave this choice to the group as to which way to proceed at the moment.

You are invited to specify your preference on list by September 25th, 2:00pm GMT.  Option A or Option B.  Please be explicit.

We can pursue one of two approaches:

Option A:  Pursue adopting a draft

The approach would be that we would adopt a draft by IETF 109 – as a starting point.  To avoid further deadlocks, there would be no “I’m not ready” option in the hum.  Authors are invited to merge and indicate open issues in drafts.  Others are invited, if they really feel the need, to create new drafts within 2-3 weeks.  If there are more than two options, the chairs will find ways to wheedle things down to get to a draft to adopt, while being sensitive to the concerns EKR and others raised about inertia of what is in a draft.  If the group would like an interim to facilitate this option, the chairs will accommodate.

Option B: Pursue open issues one by one

Pursue issues one by one to resolve on list, starting with “Do people believe that the RSE position should continue in some form?”  We would pursue from the nature of the role if we get an affirmative answer.  Other questions would follow, such as aspects of oversight and relationship to RPC.

If after the poll the group is evenly divided between these choices, in order to take the fork, the chairs will spin a spinner and make a decision.  You are encouraged to discuss these options, and may change your minds right up to the deadline.

A Plea

This program consists nearly exclusively of senior members of the community-  you are all past or current leaders of this organization with deep experience and knowledge.  We therefore hope that you will seek to find common ground with one another when you see a deadlock in view.

Brian and Eliot

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 18 Sep 2020 18:11:07 +0200

> On 2020-09-18, at 17:55, Eliot Lear <lear=[email-masked]> wrote:
> 
> […]
> Pursue issues one by one to resolve on list, starting with “Do people believe that the RSE position should continue in some form?”  

Now, what’s the difference?  Adopting a draft essentially means making at least this decision (unless we plan to adopt one draft and then incrementally turn it into the other).

I know that I can make a decision at this point, based on the information I have from both my IETF experiences and general life experience.  Other people have different experiences, hence a different perspective, and may therefore come up with a different decision.  Not sure that there is a way to somehow equalize those experiences.  What we maybe can do is discuss specific scenarios, and try to avoid process confabulation (e.g., as in “all humans SHOULD be good and wise, and therefore…”).  Choosing scenarios that have different outcomes in the different models, but aren’t realistic enough that we can discuss them with a view towards what would really happen in practice, does not help.

Grüße, Carsten

---

From: Eliot Lear <[email-masked]>
Date: Fri, 18 Sep 2020 18:22:00 +0200

> On 18 Sep 2020, at 18:11, Carsten Bormann <[email-masked]> wrote:
> 
> 
> 
> Now, what’s the difference?  

You may not have a preference and that is fine.  But others expressed a preference in our interim.  If we adopt a draft there will certainly be open issues to resolve.  There is no getting around resolving our differences.  It is a matter of which method the group wants to pursue.

> Adopting a draft essentially means making at least this decision (unless we plan to adopt one draft and then incrementally turn it into the other).

I think from the chairs' point of view, we could indeed do exactly what your parenthetical states.  Some people are uncomfortable with that approach.  We are therefore offering an alternative based on a suggestion made in the interim.

> 
> I know that I can make a decision at this point, based on the information I have from both my IETF experiences and general life experience.  Other people have different experiences, hence a different perspective, and may therefore come up with a different decision.  

It is precisely because a large number of people were not ready to make a decision that we are at this point.

Eliot

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Sep 2020 11:29:24 -0500

I have a strong preference for Option A.

Our community doesn't have a good, established process in general for 
recording the result of point-by-point discussions an an accessible form 
other than recording them in an internet draft. (I don't consider 
trolling through voluminous email archives and meeting minutes to be 
"accessible.")

We need a vehicle for tracking these decisions before we get too far 
down the path of making a long string of them. Unless we can agree on 
using some kind of issue-tracking system to record these decisions 
(which would be its own controversial bag of worms for the current set 
of participants), the conventional vehicle is an internet-draft. Let's 
get that in place and then start working on sanding down the rough edges.

/a

On 9/18/2020 10:55 AM, Eliot Lear wrote:
> The chairs have had an opportunity to discuss the last interim.  We 
> note that some people liked the comparison chart, as a means to 
> highlight both similarities and differences.   We know that some 
> people would very much like to have seen a draft adopted, while others 
> were not ready to move forward.  Several people would instead like to 
> go issue by issue and resolve those issues before adopting a draft. 
>  The chairs will leave this choice to the group as to which way to 
> proceed at the moment.
>
> You are invited to specify your preference *on list* *by September 
> 25th, 2:00pm GMT.  Option A or Option B.  Please be explicit.*
>
> *Option A:  Pursue adopting a draft*
>
> The approach would be that we *would* adopt a draft by IETF 109 – *as 
> a starting point*.  To avoid further deadlocks, there would be 
> *no* “I’m not ready” option in the hum.  Authors are invited to merge 
> and indicate open issues in drafts.  Others are invited, if they 
> really feel the need, to create new drafts within 2-3 weeks.  If there 
> are more than two options, the chairs will find ways to wheedle things 
> down to get to a draft to adopt, while being sensitive to the concerns 
> EKR and others raised about inertia of what is in a draft.  If the 
> group would like an interim to facilitate this option, the chairs will 
> accommodate.
>
> *Option B: Pursue open issues one by one*
>
> Pursue issues one by one to resolve on list, starting with “Do people 
> believe that the RSE position should continue in some form?”  We would 
> pursue from the nature of the role if we get an affirmative answer. 
>  Other questions would follow, such as aspects of oversight and 
> relationship to RPC.
>
> If after the poll the group is evenly divided between these choices, 
> in order to take the fork, the chairs will spin a spinner and make a 
> decision.  You are encouraged to discuss these options, and may change 
> your minds right up to the deadline.
>
> *A Plea*
>
> This program consists nearly exclusively of senior members of the 
> community-  you are all past or current leaders of this organization 
> with deep experience and knowledge.  We therefore hope that you will 
> seek to find common ground with one another when you see a deadlock in 
> view.
>
> Brian and Eliot
>
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 18 Sep 2020 18:37:03 +0200

Hi Adam,

> On 18 Sep 2020, at 18:29, Adam Roach <[email-masked]> wrote:
> 

Noted.  However…

> 
> Our community doesn't have a good, established process in general for recording the result of point-by-point discussions an an accessible form other than recording them in an internet draft. (I don't consider trolling through voluminous email archives and meeting minutes to be "accessible.")
> 
> We need a vehicle for tracking these decisions before we get too far down the path of making a long string of them. Unless we can agree on using some kind of issue-tracking system to record these decisions (which would be its own controversial bag of worms for the current set of participants), the conventional vehicle is an internet-draft. Let's get that in place and then start working on sanding down the rough edges.

Neither chair has difficulty with managing an issue tracker.  We can do that job just fine.  However, it may be the case that some find it difficult to resolve issues on a transactional basis outside the context of a draft.  I take no position on that.

Eliot

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 18 Sep 2020 21:06:19 +0100

I have sympathy with the “fear of inertia” you attribute to Ekr. I know that that should not happen, but I also know that it happens both consciously and subconsciously.

I agree with Adam that we work best when we record things in drafts.

What you don’t want, now that you have pinned us to an A-or-B decision, is a discussion of other options, but … 😊

Suppose we adopt an empty-ish draft (perhaps has background and objectives, perhaps has initial list of open issues/questions) and then follow option B recording each decision in the draft as it comes to (rough) consensus? 

If you wanted to stick to your A-or-B choice, I guess that is B with a plan on how to kickstart a draft and fill it in.

Best

A (the name, not the option)

From: Rfced-future <[email-masked]> On Behalf Of Eliot Lear
Sent: 18 September 2020 16:55
To: [email-masked]
Subject: [Rfced-future] Moving forward: Please state your preference

Hello everyone,

— Yogi Bera

A Plea

Brian and Eliot

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 18 Sep 2020 20:30:12 +0000

*   If you wanted to stick to your A-or-B choice, I guess that is B with a plan on how to kickstart a draft and fill it in.

Sounds like “A” to me.  Make a draft – can be done in 2-3 weeks I guess – and offer it

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Sep 2020 14:02:30 +1200

Hi,

Before answering that, I wanted to better understand the discrepancies between the models. Loosely based on Eliot's charts, I built the attached Venn diagram. It's quite subjective, and it skips over many details and subtleties. Comments are very welcome (but space for extra text is very limited).

It's still a bit complex at first sight, but I think we could reduce the strategic questions to 5 or 6. My preference is to tackle that for a few weeks, before attempting to munge the drafts.

fwiw, the SVG file format is almost ready for inclusion in an I-D.

Regards
   Brian Carpenter

On 19-Sep-20 03:55, Eliot Lear wrote:
> You are invited to specify your preference *on list* *by September 25th, 2:00pm GMT.  Option A or Option B.  Please be explicit.*
> 
> The approach would be that we *would* adopt a draft by IETF 109 – *as a starting point*.  To avoid further deadlocks, there would be *no* “I’m not ready” option in the hum.  Authors are invited to merge and indicate open issues in drafts.  Others are invited, if they really feel the need, to create new drafts within 2-3 weeks.  If there are more than two options, the chairs will find ways to wheedle things down to get to a draft to adopt, while being sensitive to the concerns EKR and others raised about inertia of what is in a draft.  If the group would like an interim to facilitate this option, the chairs will accommodate.
>

---

From: Eliot Lear <[email-masked]>
Date: Sat, 19 Sep 2020 12:09:46 +0200

> On 18 Sep 2020, at 22:06, Adrian Farrel <[email-masked]> wrote:
> 

To me this is a valid version of Option A, and we might even employ it as a means to implement Option B.  It is also possible that a draft would emerge that leaves open issues which we do not have agreement.  That would give us a bit more than a blank page.

Eliot

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 19 Sep 2020 11:11:04 +0100

Well, in that case I vote “option A and B” 😊

From: Eliot Lear <[email-masked]> 
Sent: 19 September 2020 11:10
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Rfced-future] Moving forward: Please state your preference

On 18 Sep 2020, at 22:06, Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote:

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Sat, 19 Sep 2020 13:13:56 -0400

For the same reasons we discussed on the call, I choose option C - we're 
not ready to pick a path.   That looks closer to Option B than it does 
option A but probably actually isn't the same.  We've talked about 
common solution elements, but we're still having major discussions (cf 
John and and Adam's back and forth) about the implications of various 
choices such that picking solution elements are still quite difficult.  
Among other things, many of the elements are entwined - e.g., choosing 
choice A of Group 1 may restrict your choices in Group 2 to choices C and F.

As I read it we've agreed mostly on one thing:

  * That the stream managers will take a major role in the evolution
    process of the RFC Series.

We seem to have also agreed that (I think this is what I got an 
agreement on from Martin and Brian when I asked the question on the call):

  * The LLC will be responsible for any contractual items including
    hiring/firing/renewals/day-to-day and that any delegation of that
    role will be only to a "fiduciary" of the LLC (e.g. employee or a
    contracted role) to specifically exclude the IAB/RSOC personnel
    management model.

We haven't agreed on:

  * Whether there will be a professional involved in the steering, or
    the model of engagement for that professional.  (e.g. employee or
    retained contractor with primary responsibility vs employee or
    retained contractor with advisory only responsibility or a
    professional contractor engaged only for task-specific short term
    items).

  * The model for publication of documents that drive the publication
    process.

And lots more.

I've been trying to do a topological sort and figure out which of the 
problems is the core one that we need to come to a conclusion on, and 
I'm at a loss.

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 20 Sep 2020 09:34:56 +1200

> I've been trying to do a topological sort

That's exactly why I drew my Venn diagram...

Regards
   Brian Carpenter

On 20-Sep-20 05:13, Michael StJohns wrote:
> For the same reasons we discussed on the call, I choose option C - we're not ready to pick a path.   That looks closer to Option B than it does option A but probably actually isn't the same.  We've talked about common solution elements, but we're still having major discussions (cf John and and Adam's back and forth) about the implications of various choices such that picking solution elements are still quite difficult.  Among other things, many of the elements are entwined - e.g., choosing choice A of Group 1 may restrict your choices in Group 2 to choices C and F.
> 
> 
>   * That the stream managers will take a major role in the evolution process of the RFC Series.  
> 
> We seem to have also agreed that (I think this is what I got an agreement on from Martin and Brian when I asked the question on the call):
> 
>   * The LLC will be responsible for any contractual items including hiring/firing/renewals/day-to-day and that any delegation of that role will be only to a "fiduciary" of the LLC (e.g. employee or a contracted role) to specifically exclude the IAB/RSOC personnel management model.
> 
> We haven't agreed on:
> 
>   * Whether there will be a professional involved in the steering, or the model of engagement for that professional.  (e.g. employee or retained contractor with primary responsibility vs employee or retained contractor with advisory only responsibility or a professional contractor engaged only for task-specific short term items).
> 
>   * The model for publication of documents that drive the publication process.
> 
> And lots more.
> 
> I've been trying to do a topological sort and figure out which of the problems is the core one that we need to come to a conclusion on, and I'm at a loss.
> 
> Mike
> 
> 
>

---

From: John C Klensin <[email-masked]>
Date: Sat, 19 Sep 2020 23:57:35 -0400

--On Saturday, 19 September, 2020 12:09 +0200 Eliot Lear
<lear=[email-masked]> wrote:

>> Suppose we adopt an empty-ish draft (perhaps has background
>> and objectives, perhaps has initial list of open
>> issues/questions) and then follow option B recording each
>> decision in the draft as it comes to (rough) consensus?
> 
> To me this is a valid version of Option A, and we might even
> employ it as a means to implement Option B.  It is also
> possible that a draft would emerge that leaves open issues
> which we do not have agreement.  That would give us a bit more
> than a blank page.

While I have trouble seeing it as a version of Option A --or,
more specifically, I cannot support Option A in order to get to
it because of all of the other possible versions -- it is more
or less what I suggested toward the end of the call and in an
earlier note (my) today.

  john

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 20 Sep 2020 16:10:17 +1200

> or less what I suggested toward the end of the call and in an

I agree too. Without debating the merits of over-simplification by
Venn diagram, one thing that it taught me is that separating out
the agreed from the unagreed issues is a very good first step.

   Brian

---

From: Eliot Lear <[email-masked]>
Date: Sun, 20 Sep 2020 10:06:34 +0200

That’s fine.  What you, Brian, and Mike have argued for is Option B, which is to resolve matters issue by issue.  Noted.

Eliot

> On 20 Sep 2020, at 05:57, John C Klensin <[email-masked]> wrote:
> 
> 
> 
> <lear=[email-masked] <mailto:lear=[email-masked]>> wrote:
> 
> -- 
> Rfced-future mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 20 Sep 2020 12:17:30 +0100

It may be seen as a secondary issue, but I would really like the results of deliberations in Option B to be recorded in an I-D and not some issue tracker, wiki, or github repo. When I suggested this earlier in the thread you suggested this was actually Option A because there was a draft adopted to work on. That made me say I was happy with “A+B”.

So, for the avoidance of doubt, I would like to see issues resolved one by one. That is Option B.

A

From: Eliot Lear <[email-masked]> 
Sent: 20 September 2020 09:07
To: John C Klensin <[email-masked]>
Cc: Eliot Lear <lear=[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Rfced-future] Moving forward: Please state your preference

Eliot

On 20 Sep 2020, at 05:57, John C Klensin <[email-masked] <mailto:[email-masked]> > wrote:

--On Saturday, 19 September, 2020 12:09 +0200 Eliot Lear
< <mailto:lear=[email-masked]> lear=[email-masked]> wrote:

On 18 Sep 2020, at 22:06, Adrian Farrel <[email-masked] <mailto:[email-masked]> >
wrote:

 john

-- 
Rfced-future mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.iab.org/mailman/listinfo/rfced-future> https://www.iab.org/mailman/listinfo/rfced-future

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 20 Sep 2020 13:33:00 +0200

On 2020-09-20, at 13:17, Adrian Farrel <[email-masked]> wrote:
> 
> It may be seen as a secondary issue, but I would really like the results of deliberations in Option B to be recorded in an I-D and not some issue tracker, wiki, or github repo. 

I would even more happy if we could record the rationale for the decisions as well.  Bonus, if we do this in a way an engineer can understand.

Grüße, Carsten

---

From: John C Klensin <[email-masked]>
Date: Sun, 20 Sep 2020 09:15:38 -0400

Eliot,

I don't think so, any more than I think it is really a variation
on Option A.  First, I think what I suggested --and what I think
Brian's efforts to create Venn diagrams and the like suggest --
is that "issue by issue" may be impossible (or a way to
foreclose some key topics) because of the ways in which issues
are interrelated.  Second, it is Option B only if Option B is
combined with a new I-D used as a base document that starts with
what we agree on now (if anything) and that is updated as
consensus evolves (as Adrian suggested a couple of hours ago but
was, I thought, clearly intended by my note and others) and
documents the rationale for each decision (as Carsten suggested
even more recently).

That idea has been largely consistent since the call.  Although
I suggested it on the call, it does not originate with me but
was a small consolidation of things said earlier and several
(IMO rather small and converging) variations have been suggested
since.  The very fact that you earlier suggested it was really a
variation on Option A and now suggest that it is really Option B
is more consistent with the several suggestions for "A+B", "C or
others", and, for at least some of us, "not ready" on the call
when you suggested a choice between A and B.  Of course, the
same situation implies that we could somehow all agree that the
suggestion is "really A" or "really B" but then start arguing
about what A or B "really" means, e.g., how we document the
decisions of Option B or whether Option A means starting with a
new document or whether we debate changes from existing ones.  I
don't think an apparent decision followed by that argument would
move things forward, YMMD.

I respect and appreciate your (and Brian Rosen's) desire to make
and show progress and drive things to consensus more quickly.
However, doing that by creating what some of us consider false
dichotomies and then apparently interpreting comments as
consistent with one or the other of those options does not seem
to me to be the way to do it. In a "normal" WG, I think it would
even result in appeals.

best,
   john

--On Sunday, 20 September, 2020 10:06 +0200 Eliot Lear
<[email-masked]> wrote:

> That's fine.  What you, Brian, and Mike have argued for is
> Option B, which is to resolve matters issue by issue.  Noted.
> 
> Eliot
> 
>> <lear=[email-masked]
>> <mailto:lear=[email-masked]>> wrote:
>> 
>>> which we do not have agreement.  That would give us a bit
>>> more than a blank page.
>> 
>> more specifically, I cannot support Option A in order to get
>> to it because of all of the other possible versions -- it is
>> more or less what I suggested toward the end of the call and
>> in an earlier note (my) today.
>> 
>>  john
>> 
>> 
>> 
>> -- 
>> https://www.iab.org/mailman/listinfo/rfced-future
>> <https://www.iab.org/mailman/listinfo/rfced-future>

---

From: Eliot Lear <[email-masked]>
Date: Sun, 20 Sep 2020 16:14:21 +0200

Hi John,

> On 20 Sep 2020, at 15:15, John C Klensin <[email-masked]> wrote:
> 
> Eliot,
> 
> are interrelated.

I understand your concern.  Let’s agree among ourselves that we will avoid such foreclosures in particular, and that we will work to understand such linkages.  If issues have to be taken together, let’s understand why.

>  Second, it is Option B only if Option B is

I think that’s where we are heading, but we will see what others think.  If people do not object to that idea, we as a group can act on it.

> variation on Option A

Not quite.  Option A provides us a draft upon which to build.  B states rather categorically that we don’t yet have a starting point and need to develop one.  The chairs can facilitate either approach.  We personally like A because it advances the group's efforts, but we won’t/can’t force our views on the group.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Sun, 20 Sep 2020 11:18:49 -0400

Eliot,

Very helpful, thanks.  One comment on your distinction about
Option A below.

--On Sunday, 20 September, 2020 16:14 +0200 Eliot Lear
<[email-masked]> wrote:

>> I don't think so, any more than I think it is really a
>> variation on Option A.  First, I think what I suggested --and
>> what I think Brian's efforts to create Venn diagrams and the
>> like suggest -- is that "issue by issue" may be impossible
>> (or a way to foreclose some key topics) because of the ways
>> in which issues are interrelated.
> 
> I understand your concern.  Let's agree among ourselves that
> we will avoid such foreclosures in particular, and that we
> will work to understand such linkages.  If issues have to be
> taken together, let's understand why.
> 
> 
>> combined with a new I-D used as a base document that starts
>> with what we agree on now (if anything) and that is updated as
>> consensus evolves (as Adrian suggested a couple of hours ago
>> but was, I thought, clearly intended by my note and others)
>> and documents the rationale for each decision (as Carsten
>> suggested even more recently).
> 
> I think that's where we are heading, but we will see what
> others think.  If people do not object to that idea, we as a
> group can act on it.
> 
>> 
>> That idea has been largely consistent since the call.
>> Although I suggested it on the call, it does not originate
>> with me but was a small consolidation of things said earlier
>> and several (IMO rather small and converging) variations have
>> been suggested since.  The very fact that you earlier
>> suggested it was really a variation on Option A

> Not quite.  Option A provides us a draft upon which to build.
> B states rather categorically that we don't yet have a
> starting point and need to develop one.  The chairs can
> facilitate either approach.  We personally like A because it
> advances the group's efforts, but we won't/can't force our
> views on the group.

Ok.  Option A, as I understood it from the call, was to pick one
of the remaining/existing three documents or to somehow
consolidate, I believe< Martin's and Brian's and then pick from
it and Mike's and proceed from there.   I see enough differences
(in assumptions and fundamental preferences, not just details or
text) among the three that I'm uncomfortable starting with any
of them or, more generally, any document that treats any issues
that are still controversial or dependent on unresolved others
as settled.  

And that is why I've repeatedly suggested that you find an
editor, preferably a fairly neutral one, to create a new I-D.
Its initial version would record the issues on which we have
agreement --issues we can also agree are either independent of
others or where the whole cluster has been resolved.  It could
either stop there or catalog (without taking or implying any
conclusions) known controversial principles and/or specific
outstanding issues.  Then, as we sort things out, it would then
be revised to include additional decisions and the reasons for
them.  

Certainly that is, as you suggested, a variation on A.  Or maybe
it is a derivation from A. Certainly it uses a document as a
starting point rather than trying to sort out issues one at a
time without a document. 

It can also reasonably be interpreted as a variation on, or
derivation from, B because it assumes that we don't have a
starting point today and proposes a new draft, free of the
baggage and implied conclusions of the existing ones, as a first
step in developing a starting point.

But, unless you want to redefine A and then restate the question
(or similarly redefine B), it is not A (or B)... I am
indifferent as to whether we call it A' (or B') or D (in
deference to Mike's C).  In a way it is an A-B hybrid, so
perhaps it is Option AB or BA.

thanks,
    john

p.s. Having proposed it, I should perhaps volunteer to
edit/author the proposed new draft.  I might be willing to try
it if you can't find someone else.  But my positions on these
issues are quite strong (as I'm sure most of those reading this
have figured out and why I suggested the IAB not put me in the
position you are now in.  That would make it hard for me to edit
a document fairly and even harder for many people on this list
to believe it had been done fairly, creating even more
controversy.  That is why I have not volunteered yet and why I
think my doing that job would be a bad idea.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 20 Sep 2020 11:28:05 -0400

As far as I can tell, option A is at this point a pig in a poke.  We 
commit (for some meaning of commit) to adopting a draft.  Without 
knowing what the possible drafts are or how we will pick among the 
presumably several drafts?

It would be pretty hard to object to a skeletal drafts.  I can even see 
a good argument for the group owning the skeletal draft, so that the 
only things that get in are things on which there is rough consensus.

What I do not see is how that corresponds to either of the options you 
put on the table.

Just for completeness, I will state publicly what I said to you 
privately.  As far as I can tell, option A as origianlly stated is not 
even a procedurally valid option.  And I would object to efforts to 
force it.  As defined, it would require adopting a draft, by means 
defined by the chairs, even if there is no rough consensus on a single 
draft.  That is just wrong.  Even in the softwires case that comes 
closest to this, the WG knew what the alternatives were, and knew what 
the decision procedure was.

Yours,
Joel

On 9/20/2020 10:14 AM, Eliot Lear wrote:
> Hi John,
> 
>> On 20 Sep 2020, at 15:15, John C Klensin <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Eliot,
>>
> I understand your concern.  Let’s agree among ourselves that we will 
> avoid such foreclosures in particular, and that we will work to 
> understand such linkages.  If issues have to be taken together, let’s 
> understand why.
> 
> 
> I think that’s where we are heading, but we will see what others think. 
>   If people do not object to that idea, we as a group can act on it.
> 
>>
> Not quite.  Option A provides us a draft upon which to build.  B states 
> rather categorically that we don’t yet have a starting point and need to 
> develop one.  The chairs can facilitate either approach.  We personally 
> like A because it advances the group's efforts, but we won’t/can’t force 
> our views on the group.
> 
> Eliot
>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 21 Sep 2020 13:57:34 +1000

+1 to this (Joel's) general sentiment. Discussion has made it clear that the distinction between A and B is not well-described. My sense is that the best way forward is to document the agreed-upon aspects as well as the open issues, and proceed (acknowledging that we still have some difficult - and intertwined - discussions ahead of us).

*How* we document those things isn't terribly important, but the obvious tools we have are a draft for the former, and an issues list for the latter.

Cheers,

> On 21 Sep 2020, at 1:28 am, Joel M. Halpern <[email-masked]> wrote:
> 
> As far as I can tell, option A is at this point a pig in a poke.  We commit (for some meaning of commit) to adopting a draft.  Without knowing what the possible drafts are or how we will pick among the presumably several drafts?
> 
> It would be pretty hard to object to a skeletal drafts.  I can even see a good argument for the group owning the skeletal draft, so that the only things that get in are things on which there is rough consensus.
> 
> What I do not see is how that corresponds to either of the options you put on the table.
> 
> Just for completeness, I will state publicly what I said to you privately.  As far as I can tell, option A as origianlly stated is not even a procedurally valid option.  And I would object to efforts to force it.  As defined, it would require adopting a draft, by means defined by the chairs, even if there is no rough consensus on a single draft.  That is just wrong.  Even in the softwires case that comes closest to this, the WG knew what the alternatives were, and knew what the decision procedure was.
> 
> Yours,
> Joel
> 
>>> On 20 Sep 2020, at 15:15, John C Klensin <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Eliot,
>>> 
> [email-masked]

--
Mark Nottingham   https://www.mnot.net/

---

From: Eliot Lear <[email-masked]>
Date: Mon, 21 Sep 2020 13:49:37 +0200

Well.  Apparently the chairs have found a way to gather consensus on at least one point after all, just not in the way we had expected ;-) 

>  My sense is that the best way forward is to document the agreed-upon aspects as well as the open issues, and proceed (acknowledging that we still have some difficult - and intertwined - discussions ahead of us).

Is there any objection to proceeding along the lines that Mark suggested?

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Sep 2020 13:35:51 +1200

> Is there any objection to proceeding along the lines that Mark suggested?

I found the easiest way to answer that was to try. The answer is that I have no objection, but it may prove hard to separate the discussion points. Anyway, here's my attempt at three lists (generally agreed, primary issues, secondary issues).

# Generally Agreed

LLC legally & finanicially responsible for all contracts.

RFC production and publishing are service contract(s).

Streams have content control.

A separate body debates strategy.

This body must include stream representatives.

Strategy body meetings are public.

# Open Issues (primary)

There is a figurehead and thought leader of some kind.

This figurehead is a paid expert in technical publishing.

The expert is an advisor (RSA) vs an executive editor (RSE).

The strategy body is open to all (rough consensus WG model) or has defined membership (RSEB model).

The strategy body has neutral chairs vs the RSE chairs it.

The strategy body makes final decisions on strategy vs the RSE makes final decisions.

Oversight/appeals remains with the IAB vs moves to ISOC vs moves to RSEB.

# Open Issues (secondary)

Single contract for REP vs separate contracts for production (RPC) & publication.

Contract monitor(s) outside LLC?

Membership definition (RSEB model).

Decider for hiring RSA/RSE?

Search committee for hiring RSA/RSE?

There is a new, separate Editorial Stream.

What is strategic (pragmatic definition needed)?

Regards,
    Brian

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 Sep 2020 12:59:20 +0200

Thank you, Brian.  I remind others, if you have objections to the direction Mark suggested, place state them now.  Please also see below.

> On 24 Sep 2020, at 03:35, Brian E Carpenter <[email-masked]> wrote:
> 

Does anyone disagree with the list above?  Are there other things upon which we agree?

> What is strategic (pragmatic definition needed)?

Putting aside what is primary and secondary, do people agree with the list above?  Are there other differences that need to be documented, or are there other topics that need to be raised that have not been (and this is not the last time I will ask that question)?

Eliot

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 24 Sep 2020 08:54:51 -0700

> defined membership (RSEB model).

I this is two issues combined into one, and it would be helpful if the
group could make sure both are addressed:

1. Who can participate in the meetings
2. Who can observe the meetings

The second being "transparency"; using just open/closed terminology
tends to conflate both of these topics together and they should probably
be discussed independently.  (though if you have an
anyone-can-participate membership, the observation question mostly goes
away.  Mostly.)
-- 
Wes Hardaker
USC/ISI

---

From: Jay Daley <[email-masked]>
Date: Fri, 25 Sep 2020 07:59:11 +1200

One comment below

> On 24/09/2020, at 10:59 PM, Eliot Lear <lear=[email-masked]> wrote:
> 

> Putting aside what is primary and secondary, do people agree with the list above?  Are there other differences that need to be documented, or are there other topics that need to be raised that have…

My reading of it is that there is not necessarily a disagreement here, but what we have it one proposed process for hiring an RSA and a different proposed process for hiring an RSE, and while people disagree on the need for an RSA vs an RSE they don’t appear to disagree on the appropriateness of each process for each role.  Assuming I’ve read things correctly.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Thu, 24 Sep 2020 17:06:55 -0400

Jay,

I agree with one qualification, which may re-muddy the waters.
See below.

--On Friday, September 25, 2020 07:59 +1200 Jay Daley
<[email-masked]> wrote:

>> Putting aside what is primary and secondary, do people agree
>> with the list above?  Are there other differences that need
>> to be documented, or are there other topics that need to be
>> raised that have not been (and this is not the last time I
>> will ask that question)?
> 
> My reading of it is that there is not necessarily a
> disagreement here, but what we have it one proposed process
> for hiring an RSA and a different proposed process for hiring
> an RSE, and while people disagree on the need for an RSA vs an
> RSE they don't appear to disagree on the appropriateness of
> each process for each role.  Assuming I've read things
> correctly.

ARAICT, you have read those parts of the discussions correctly.
_However_ this is one of interaction issues.  I don't know how
many others are like me in this regard, but "how to recruit and
hire X" is not a question I choose to spend time thinking much
about, much less commenting on, before we have figured out
whether we want and RSE or RSA (and probably more than we have
today about what those roles mean).  Phrases like "cart before
the horse" come to mind.  Consequently, you've seen no comments
on the subject from me, and making inferences about agreement
about either process may be unjustified.  

The one piece of the subject about which I do have a strong
opinion is that I think it would be a terrible idea to chose
between RSE and RSA-type roles based on what we believe would be
the ease of recruiting and retaining one or the other.  AFAIK,
no one has suggested that, but it could easily be a result,
possibly unintentional, of concentrating on selection processes
rather than the relationship between the roles.

    john

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 25 Sep 2020 07:28:48 +1000

> group could make sure both are addressed:

Brian addressed this by noting that all proposals include public meetings, just that Mike proposed a closed membership.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Sep 2020 09:35:10 +1200

> 2. Who can observe the meetings

I agree; that should be expressed more clearly.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Sep 2020 09:38:06 +1200

> about either process may be unjustified.  

That's exactly why I listed it as "secondary". There's little
point in debating it in a vacuum.

> rather than the relationship between the roles.

Agreed.

    Brian

---

From: Jay Daley <[email-masked]>
Date: Fri, 25 Sep 2020 09:40:13 +1200

> On 25/09/2020, at 9:38 AM, Brian E Carpenter <[email-masked]> wrote:
> 

My point was that it isn’t even a secondary issue - it’s not an issue at all afaict.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 Sep 2020 14:48:57 -0700

On Thu, Sep 24, 2020 at 12:59 PM Jay Daley <[email-masked]> wrote:

> > Putting aside what is primary and secondary, do people agree with the
> list above?  Are there other differences that need to be documented, or are
> there other topics that need to be raised that have not been (and this is
> not the last time I will ask that question)?
>
> My reading of it is that there is not necessarily a disagreement here, but
> what we have it one proposed process for hiring an RSA and a different
> proposed process for hiring an RSE, and while people disagree on the need
> for an RSA vs an RSE they don’t appear to disagree on the appropriateness
> of each process for each role.  Assuming I’ve read things correctly.
>

No, I don't think you have. Mike and I had an extended back and forth about
RSE hiring and our disagreement on that.

-Ekr

---

From: John C Klensin <[email-masked]>
Date: Thu, 24 Sep 2020 18:24:56 -0400

--On Friday, September 25, 2020 09:40 +1200 Jay Daley
<[email-masked]> wrote:

>>> ARAICT, you have read those parts of the discussions
>>> correctly. _However_ this is one of interaction issues.  I
>>> don't know how many others are like me in this regard, but
>>> "how to recruit and hire X" is not a question I choose to
>>> spend time thinking much about, much less commenting on,
>>> before we have figured out whether we want and RSE or RSA
>>> (and probably more than we have today about what those roles
>>> mean).  Phrases like "cart before the horse" come to mind.
>>> Consequently, you've seen no comments on the subject from
>>> me, and making inferences about agreement about either
>>> process may be unjustified.  
>> 
> My point was that it isn't even a secondary issue - it's
> not an issue at all afaict.

I'm not sure whether Brian's definition of "secondary" and mine
are the same, which is why I keep saying "intertwined",
"interconnected", and "mutually dependent", although I I believe
we agree that anything that helps us sequence our consideration
of these issues is a good idea and that this one comes after
deciding among RS* models.  But "not an issue at all" is going
too far for at least two reasons.  One is that people who have
been ignoring the "how we recruit and hire" question entirely
until we after the "RSE vs RSA" decision is made might then
review the plans for the chosen position and raise issues that
have not yet been identified, much less discussed.  The other is
that once that decision is made and we have agreed-upon scope
and job description statements, we review the
recruitment/selection plan and discover that the number of
people who would meet the requirements and be willing to apply
or or take the position would be somewhat more rare than the
typical unicorn or flying pig.  We would then have to figure out
something else, possibly revisiting already-closed decisions.
I think (and hope) the latter scenario is unlikely but not
unlikely enough to say "not an issue at all".

    john

---

From: Jay Daley <[email-masked]>
Date: Fri, 25 Sep 2020 10:39:19 +1200

> On 25/09/2020, at 9:48 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Thu, Sep 24, 2020 at 12:59 PM Jay Daley <[email-masked] <mailto:[email-masked]>> wrote:
> One comment below
> 
> > On 24/09/2020, at 10:59 PM, Eliot Lear <lear=[email-masked] <mailto:[email-masked]>> wrote:
> > 
> No, I don't think you have. Mike and I had an extended back and forth about RSE hiring and our disagreement on that.

Ah. Thanks!

Jay

> [email-masked] <mailto:[email-masked]>
> 
> -- 
-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 Sep 2020 16:25:17 -0700

On Thu, Sep 24, 2020 at 3:59 AM Eliot Lear <lear=[email-masked]>
wrote:

> Thank you, Brian.  I remind others, if you have objections to the
> direction Mark suggested, place state them now.  Please also see below.
>
> Well.  Apparently the chairs have found a way to gather consensus on at
> least one point after all, just not in the way we had expected ;-)
>
>
>
> My sense is that the best way forward is to document the agreed-upon
> aspects as well as the open issues, and proceed (acknowledging that we
> still have some difficult - and intertwined - discussions ahead of us).
>
>
>
> I found the easiest way to answer that was to try. The answer is that I
> have no objection, but it may prove hard to separate the discussion points.
> Anyway, here's my attempt at three lists (generally agreed, primary issues,
> secondary issues).
>
> # Generally Agreed
>
I'm not sure what this means. Suppose we have a WG as MT's version
suggests. What does this mean for the IETF stream in practice?

> These first two don't have alternatives. Is the point that there is an
open issue about whether they are agreed as stated?

-Ekr

> Putting aside what is primary and secondary, do people agree with the list
> above?  Are there other differences that need to be documented, or are

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Sep 2020 12:38:15 +1200

On 25-Sep-20 11:25, Eric Rescorla wrote:
> 
> 
> On Thu, Sep 24, 2020 at 3:59 AM Eliot Lear <lear=[email-masked] <mailto:[email-masked]>> wrote:
> 
>>     On 24 Sep 2020, at 03:35, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>
> I'm not sure what this means. Suppose we have a WG as MT's version suggests. What does this mean for the IETF stream in practice?

Martin's draft says: "stream managers are expected to initiate discussion or make proposals to the RFC Series Evolution program. To avoid conflicts of interest, it is expected that stream managers will be active participants - and not chairs - in this group." (My draft says essentially the same.) I think we both assume that the IETF will name an individual as stream manager, since I doubt if any IETF Chair will want yet another job.

> These first two don't have alternatives. Is the point that there is an open issue about whether they are agreed as stated?

Yes, I think so, because draft-thomson doesn't have this and the other two drafts do.

Regards
    Brian

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 Sep 2020 17:45:06 -0700

On Thu, Sep 24, 2020 at 5:38 PM Brian E Carpenter <
[email-masked]> wrote:

> > On Thu, Sep 24, 2020 at 3:59 AM Eliot Lear <lear=
> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >>     On 24 Sep 2020, at 03:35, Brian E Carpenter <
> [email-masked] <mailto:[email-masked]>> wrote:
> >>
> >>>     Well.  Apparently the chairs have found a way to gather consensus
> on at least one point after all, just not in the way we had expected ;-)
> >>>
> >>>
> >>>
> >>>>     My sense is that the best way forward is to document the
> agreed-upon aspects as well as the open issues, and proceed (acknowledging
> that we still have some difficult - and intertwined - discussions ahead of
> us).
> >>>
> >>>
> >>     I found the easiest way to answer that was to try. The answer is
> that I have no objection, but it may prove hard to separate the discussion
> points. Anyway, here's my attempt at three lists (generally agreed, primary
> issues, secondary issues).
> >>
> >>     # Generally Agreed
> >>
> Martin's draft says: "stream managers are expected to initiate discussion
> or make proposals to the RFC Series Evolution program. To avoid conflicts
> of interest, it is expected that stream managers will be active
> participants - and not chairs - in this group." (My draft says essentially
> the same.) I think we both assume that the IETF will name an individual as
> stream manager, since I doubt if any IETF Chair will want yet another job.
>

This text is sufficiently fuzzy that I think it's fine. What I don't think
we have agreement on -- and I don't think we should do -- is to give them
special privileges (e.g., be required for quorum, be the only people who
can propose things, have a veto, etc.)

-Ekr

> >     Putting aside what is primary and secondary, do people agree with
> the list above?  Are there other differences that need to be documented, or
> are there other topics that need to be raised that have not been (and this
> is not the last time I will ask that question)?
> >
> >     Eliot
> >
> >     --

---

From: John C Klensin <[email-masked]>
Date: Thu, 24 Sep 2020 22:40:26 -0400

--On Friday, September 25, 2020 12:38 +1200 Brian E Carpenter
<[email-masked]> wrote:

>...
> I think we both assume that the IETF will name an individual
> as stream manager, since I doubt if any IETF Chair will want
> yet another job.

IMO, it would be good to nail that down (rather than assume it)
because any IETF Chair who would want more roles probably takes
us down the path toward royalty (in the sense of those kings
(and queens) we don't believe in).

   john