Subject: [Rfced-future] Summary points, tracking, discussing, etc

From: Eliot Lear <[email-masked]>
Date: Fri, 24 Apr 2020 08:20:50 +0200

Hi everyone,

After a healthy start to the discussion, as I mentioned previously I’ve tried to boil things down a bit.  I am attaching the summary points below again, for people to see.  And as I wrote previously, they each have a “?” at the end.  It seems to me these are all good points to at least address in discussion.  It’s been suggested to me privately that it may be useful to rank these.  That way, we can get a notion of what people would like to work on first.  I am also thinking that these are our first “issues" to track.  These issues also help form the contours of a problem statement.  As we begin to zero in on that, we can start to also think about solutions.  Moving forward on this part, therefore, helps us get toward the meat of our work.

A word or two about modalities (again), it seems to me that having some cadence of web conferences will help move things along.  Therefore, I propose to set up two meetings per month, with varying times to accommodate different locales (spreading the pain), starting in mid-May, arranging around the IETF plenary meeting (either f2f or virtually).  My preference is that the meetings run somewhat informally. By participant count we’re not that large a group, and I would rather we not get too “over processed”.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Fri, 24 Apr 2020 08:21:28 +0200

And this time with the summary points at the bottom...

> On 24 Apr 2020, at 08:20, Eliot Lear <[email-masked]> wrote:
> 
> Hi everyone,
> 

 <https://github.com/intarchboard/rfced-future/blob/master/PossibleGoalsandPointsMade.md#the-roles>The role(s)

Sets strategy?
Having an understanding of archival tools is important for the role
What technical capabilities should the RFC Editor be expected to have
Responsibility for the RPC and its budget?
Authority to impose minimum standards for editing of docs
Tooling responsibility?
Responsibility to set publishing standards?
Compliance with publication standards?
Establishing/overseeing formal processes to determine the value of RFCs to societies?
Provides recommendations to make series more accessible to the various audiences?
 <https://github.com/intarchboard/rfced-future/blob/master/PossibleGoalsandPointsMade.md#relationships-and-lines-of-responsibility-and-transparency>
Relationships and lines of responsibility, and transparency

Where does the role fit in?
What are the roles?
 <https://github.com/intarchboard/rfced-future/blob/master/PossibleGoalsandPointsMade.md#what-we-want-from-the-series>
What we want from the series

Record agreements
Timely publication
Copy editing can slow that process
Role should fit existing organizational structure
Bespoke tooling is a bug not a feature
Should we worry about legacy?
What happens to the series if the IETF disappears
What happens to the IETF if the series disappears
Ease of navigation?

---

From: "Bron Gondwana" <[email-masked]>
Date: Sat, 25 Apr 2020 10:19:49 +1000

On Fri, Apr 24, 2020, at 16:21, Eliot Lear wrote:
>  * What happens to the series if the IETF disappears
>  * What happens to the IETF if the series disappears

These two are really interesting questions, but they're only half the thing to consider here. I'm part of volunteer organisation which has existed for over 50 years, and during the past 20 years that I've been a member I've seen multiple things which were definitely not "disappears" but have been pretty bad sicknesses - for example there is a bank account which nobody was able to access for about 10 years because the signatories served out their terms and then went radio silence or became obstinate about handing them on to the next elected because of queries over the governance of the organisation and the validity of elections.

It's not like this organisation has "disappeared" - parts of it are still running effectively, but other parts really aren't very well.

So I'd say that rather than just disappear - we need to consider all of this triple:
* What if X disappears entirely in a way that it can't be effectively forked/restarted.
* What if X evolves so fast that it no longer serves the needs of Y
* What if X becomes so {dysfunctional/slow/mired in internal process} that it no longer serves the needs of Y in a timely manner

All of those apply both ways to the quoted questions :)

Cheers,

Bron.

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Apr 2020 01:33:41 +0100

Hiya,

> All of those apply both ways to the quoted questions :)

FWIW, I think that's an improvement on the questions
Eliot posed. I don't know if it gets us to to a useful
enough set of questions though.

Maybe we ought wonder more concretely: "the RSE can be
more or less independent of the IETF - what's the best
level of (in)dependence?"

Cheers,
S.

---

From: Jay Daley <[email-masked]>
Date: Sat, 25 Apr 2020 17:49:11 +1200

Stephen

> On 25/04/2020, at 12:33 PM, Stephen Farrell <[email-masked]> wrote:
> 
> more or less independent of the IETF

Can you explain why you think that is a given rather than something to be assessed by analysis?

thanks
Jay

> - what's the best
> <0x5AB2FAF17B172BEA.asc>-- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

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

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Apr 2020 15:33:20 +0100

Hiya,

On 25/04/2020 06:49, Jay Daley wrote:
>> Maybe we ought wonder more concretely: "the RSE can be more or less
>> independent of the IETF
> 

I must be missing something because the part of my
statement quoted above seems like a tautology to me.

Maybe rephrasing it will make that clearer: the level of
independence the RSE has from the IETF could vary. (That's
the tautological bit.) The community, however defined, (*)
should discuss what's the best level of independence. (That
bit isn't a tautology.)

Does that help? If so, my reason for suggesting the latter
bit is that I think non-crazy members of the IETF community
have wildly different ideas about the right thing here.
This particular discussion might be better earlier or
later in the process though, I'm not sure, but that's what
Eliot gets the big bucks for;-)

Cheers,
S.

(*) As we've seen the definition of community is a separate
topic of discussion, and of course, none of the discussions
here ought be driven by the IAB, nor LLC, though of course
people on the IAB or employed by the LLC ought contribute,
carefully, as evidenced by this exchange:-)

> 
> thanks Jay
> 
>> - what's the best level of (in)dependence?"
>> 
>> Cheers, S.
>> 
>> 
>> <0x5AB2FAF17B172BEA.asc>-- Rfced-future mailing list 
>> [email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Sat, 25 Apr 2020 21:25:01 +0200

> On 25 Apr 2020, at 16:33, Stephen Farrell <[email-masked]> wrote:
> 
> Signed PGP part
> 
> Hiya,
> 

We do need to have that conversation, and several others; and I will be prodding people on those points as soon as we sew up what other questions need answering.

Which reminds me.  What other questions need answering?

;-)

Eliot

---

From: Jay Daley <[email-masked]>
Date: Sun, 26 Apr 2020 07:30:39 +1200

> On 26/04/2020, at 2:33 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
>>> On 25/04/2020, at 12:33 PM, Stephen Farrell
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> Does that help?

Yes that makes sense - thanks.  

Jay

> If so, my reason for suggesting the latter
> [email-masked] <mailto:[email-masked]>
> https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
-- 
Jay Daley
IETF Executive Director
[email-masked]