Subject: And a third [was: A couple of opinion pieces]

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Jul 2019 16:19:19 +1200

Various recent discussions here have made me think that the IETF is
at a point where some fundamentals in the standards process, the
publication process, and its basic organization need to be re-evaluated
and perhaps changed. The goal of course would be to make the IETF more
useful, not change for its own sake.

It's above my pay grade to decide whether to start an organized
approach to this, but in addition to the two opinion pieces mentioned
below, please also consider this:
https://www.cs.auckland.ac.nz/~brian/CommentaryIAB.pdf
This is about the institution, not the people. Please read the opening
disclaimer, and of course comments are welcome, as always.

Regards
   Brian Carpenter

On 20-Jun-19 16:24, Brian E Carpenter wrote:
> Hi,
> 
> The first document is early input to the 2019-2020 NomCom and to
> all those thinking of volunteering for it, or for any of the
> open leadership positions:
> 
> Some Thoughts on IETF Community Leadership
> https://tools.ietf.org/html/draft-carpenter-community-leaders-01
> 
> The second one is also relevant to NomCom, but also to those who
> will be involved in the process of identifying the future RFC Series
> Editor, and to those who care about the IETF standards process in general:
> 
> Request for Comments
> https://tools.ietf.org/html/draft-carpenter-request-for-comments-01
> 
> Comments are most welcome, but these documents are both personal opinions.
>  
> Regards
>    Brian Carpenter
>

---

From: Melinda Shore <[email-masked]>
Date: Sun, 14 Jul 2019 21:00:44 -0800

Thanks, Brian, for these documents, and while I worry a bit
that they're a response to a specific situation and may not
be asking quite the right set of questions with respect to the
future of the IETF, I do think it's time to revisit some
really fundamental questions about how we're structured.
The formation of the LLC makes some of these questions a bit
more timely, but even so I've been struck that we don't always
have the clarity we need around things like responsibility
and accountability, and how information flows through the
organization.  The IAB has been taking steps to be more
transparent but to be totally candid there's been some
compartmentalization of information which is fine in theory
but makes accountability extremely difficult in practice.

I'll add that because we make process changes through
document development and through our consensus process (such
as it is), it's difficult to be agile in the face of
changing circumstances and changing demands, and that's a
non-trivial problem.

Years ago Avri and I co-chaired the "problem" working group,
which was charged with documenting structural problems in the
IETF that needed to be addressed.  In practice it turned out
to be month upon month of kvetching and I think did more harm
than good.  I'd like to see a way forward that doesn't repeat
that mistake but based on the quality of discussion on this list
and elsewhere about the RSE situation I am not particularly
optimistic.

But, I do agree that for the health of the organization we
need to figure out how to work through this.  What we're doing
right now isn't working well.

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: Jari Arkko <[email-masked]>
Date: Mon, 15 Jul 2019 12:11:17 +0300

Thanks for this, Brian.

It is always valuable to reconsider things, particularly looking at the big picture & whose role is what.

There’s a lot to think about of course. And I agree with Melinda about the need to consider things from a long-term perspective rather than reacting to a particularly painful issue. 

But after a quick read I did want to say that I agree with most of the observations you had.

Although I don’t necessarily agree with everything. Being particularly interested in IANA, this part caught my eye for instance. You wrote:
> This model was consolidated by the IETF-ICANN MoU [RFC2860] and subsequent supplementary agreements, formerly between ICANN and ISOC, now between ICANN and IETF LLC. In practice the IAB has no active role here and technical instructions to IANA come from the IESG, usually in the form of approved RFCs. A major difference from the RFC Editor situation is that IANA is a function executed by a completely independent corporate entity with its own revenue stream. It is unclear to me that the IAB has any meaningful oversight role in the current situation. 
> 

To begin with, the current model with IANA is working very well. It is stable, serves IETF well, there’s appropriate amount of IETF control, from my observation point at least the relevant relationships are all good, and from a worldwide perspective the IANA system is in good hands.

But I think there’s more to the system than what you write above. Obviously, on the IETF side the technical input (particularly regarding content) comes from the IESG, and the LLC signs the contract. That being said, the Trust owns the IPRs, there’s the CCG among the different communities using IANA, the IAB has an IANA program, and so on. The IAB IANA program is (thankfully) in a monitoring-that-everything-is-running-smoothly mode. It has no operational role or formal role in contracts, as described in https://www.iab.org/activities/programs/iana-program <https://www.iab.org/activities/programs/iana-program>. However, we do give advice regarding revisions to yearly SLA contracts, for instance, and keep monitoring what’s going on, and thinking when the system needs changes. A few years ago when the system needed an overhaul, many groups had plenty of work to do. In the IETF the working group and the IAB did most of the heavy lifting.

From my perspective the IANA system (incl. the role for the IAB) is working well. We should not change the engines from this flying airplane :-)

Jari

---

From: Christian Huitema <[email-masked]>
Date: Mon, 15 Jul 2019 09:22:30 -0700

Brian,

This is an interesting piece, and I share your assessment of the IAB's
situation in the late 90's. But I continue to be very skeptical of your
references to a "much wider community".

To assess that, I just did a small exercise of listing all the RFC
published in the "independent" stream in 2018. There are 14 such RFC:
8507, 8494, 8493, 8492, 8483, 8479, 8433, 8409, 8374, 8369, 8367, 8351,
8328 and 8324. 8369 is an April's fool RFC. RFC 8367 and 8369 were
published on 1 April 2018. I looked at the authors of these RFC, and did
a quick check: are these outsiders, part of a "wider community" or are
these people who are also contributing to the IETF. The overwhelming
response is, "insiders". Pretty much all the authors are or were
involved in the IETF, many of them with a prominent track record. There
are just 2 exceptions, a single RFC in which only 3 of the 5 authors are
well associated with the IETF.

There may well be a wider community of people who could publish
independent RFC, or for that matter who could participate in the IETF.
But data analysis does not indicate that these people participate in the
RFC series.

-- Christian Huitema

---

From: Leif Johansson <[email-masked]>
Date: Mon, 15 Jul 2019 19:36:45 +0200

Skickat från min iPhone

> 15 juli 2019 kl. 18:22 skrev Christian Huitema <[email-masked]>:
> 
> Brian,
> 

cf my post elsewhere on this list on how digital identitiy development moved away from pkix (and the IETF)

This seems like a perfect illustration of the streetlight effect (I admit I had to make google find the name for me). 

We have no knowledge of why other communities choose not to publish in the RFC series because we don’t have data about any other communities. 

qed - unless... you go talk to some other SDOs and similar organisations... almost like a liason-function might.

Cheers Leif

---

From: Richard Barnes <[email-masked]>
Date: Mon, 15 Jul 2019 14:15:46 -0400

On Mon, Jul 15, 2019 at 1:37 PM Leif Johansson <[email-masked]> wrote:

> This seems like a perfect illustration of the streetlight effect (I admit
> I had to make google find the name for me).
>
> We have no knowledge of why other communities choose not to publish in the
> RFC series because we don’t have data about any other communities.
>

This seems to presume that it would be desirable for other communities to
publish in the RFC series.  (I presume you mean, "other than the
IETF/IAB/IRTF community".)  Is that your belief, and if so, could you say
why?

--Richard

>
> qed - unless... you go talk to some other SDOs and similar
> organisations... almost like a liason-function might.
>
> Cheers Leif
>
> > -- Christian Huitema
> >
> >

---

From: Leif Johansson <[email-masked]>
Date: Mon, 15 Jul 2019 20:19:36 +0200

Skickat från min iPhone

> 15 juli 2019 kl. 20:15 skrev Richard Barnes <[email-masked]>:
> 
> 
> 
> This seems to presume that it would be desirable for other communities to publish in the RFC series.  (I presume you mean, "other than the IETF/IAB/IRTF community".)  Is that your belief, and if so, could you say why?

No I don’t

A more interesting question is this: what happened to make the openidc (to pick a random example) not even consider making RFCs their publication ”format”.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 15 Jul 2019 20:30:07 +0200

Skickat från min iPhone

> 15 juli 2019 kl. 20:19 skrev Leif Johansson <[email-masked]>:
> 
> 
> 
> Skickat från min iPhone
> 

I should have said: ”not anymore”

---

From: Richard Barnes <[email-masked]>
Date: Mon, 15 Jul 2019 14:29:59 -0400

On Mon, Jul 15, 2019 at 2:19 PM Leif Johansson <[email-masked]> wrote:

>> We have no knowledge of why other communities choose not to publish in
>> the RFC series because we don’t have data about any other communities.
>>
>
> A more interesting question is this: what happened to make the openidc (to
> pick a random example) not even consider making RFCs their publication
> ”format”.
>

Now I'm confused.  If it's not desirable for other communities to publish
RFCs, why does this question matter?

--Richard

---

From: Leif Johansson <[email-masked]>
Date: Mon, 15 Jul 2019 20:33:44 +0200

Skickat från min iPhone

> 15 juli 2019 kl. 20:29 skrev Richard Barnes <[email-masked]>:
> 
>  
> 
> Now I'm confused.  If it's not desirable for other communities to publish RFCs, why does this question matter?
> 

Because if we can figure out what we did (if anything) to discourage this then maybe there some useful clue to be had there.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 15 Jul 2019 10:36:03 -0800

On 7/15/19 10:19 AM, Leif Johansson wrote:
> A more interesting question is this: what happened to make the openidc
> (to pick a random example) not even consider making RFCs their
> publication ”format”..

I talked quite a bit with a well-known distributed ledger
project that was looking for a governance structure, and
ultimately they decided that they didn't want to surrender
change control or IPR to the IETF, which is reasonable.

However, there are a number of other reasons why someone
might not want to publish with us, whether it's that we're
just plain slow, that our culture is harsher than other
technical communities, or a number of other factors.   I'd like
to think that it's possible that these are problems that can be
remedied but I suspect that a good place to start would be with
looking at how we're structured rather taking on yet another
ocean-boiling exercise.

Melinda

-- 
Melinda Shore
[email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Jul 2019 14:37:59 -0400

On Mon, Jul 15, 2019 at 5:12 AM Jari Arkko <[email-masked]> wrote:

> To begin with, the current model with IANA is working very well. It is
> stable, serves IETF well, there’s appropriate amount of IETF control, from
> my observation point at least the relevant relationships are all good, and
> from a worldwide perspective the IANA system is in good hands.
>

The Titanic was working well till it hit the iceberg.

The problem I see is that we have a bunch of nation state actors who think
they should have control over the development of Internet standards. And
rightly or wrongly, some of those actors see IANA as a control point.

Of course it is easy to dismiss concerns of this type as fear mongering. I
did note that not a single one of the people who accused me of fear
mongering and attempting to distract with false accusations when I reported
that the IRG attacked one of my then employer's affiliates almost a decade
ago apologized or even admitted making an error when the attribution was
confirmed by Google when they identified an attack on another CA that was
actually successful.

---

From: Keith Moore <[email-masked]>
Date: Mon, 15 Jul 2019 14:45:49 -0400

On 7/15/19 2:37 PM, Phillip Hallam-Baker wrote:

>
> The problem I see is that we have a bunch of nation state actors who 
> think they should have control over the development of Internet 
> standards. And rightly or wrongly, some of those actors see IANA as a 
> control point.

This was certainly quite evident in the late 1990s.   Even though the 
situation seems more stable now, I doubt that all of those actors have 
given up.

Keith

---

From: Leif Johansson <[email-masked]>
Date: Mon, 15 Jul 2019 22:20:08 +0200

>     No I don’t
> 
>     A more interesting question is this: what happened to make the
>     openidc (to pick a random example) not even consider making RFCs
>     their publication ”format”.
> 
> 
> Now I'm confused.  If it's not desirable for other communities to
> publish RFCs, why does this question matter?

reading this again I understand why this would be confusing - let
me clarify:

- I personally think it would have been desirable to broaden the
use of the RFC series even at the expense of less IETF control. As
Brian remarked in one of his notes, the RFC series is the original
OA publishing channel - a thing of great value in itself.

- I don't know (but I don't expect) any outside organizations
or groups entertain any notions of a separate RFC stream by now.

- I think it might be a good idea to figure out why it is so
diffucult for us to attract communities to come and publish
on /our/ terms. Melissa has suggested IPR as one cause. There
are probably other reasons (discussion climate etc).

	Cheers Leif

---

From: Keith Moore <[email-masked]>
Date: Mon, 15 Jul 2019 16:34:59 -0400

On 7/15/19 4:20 PM, Leif Johansson wrote:

> use of the RFC series even at the expense of less IETF control.

Perhaps the biggest problem I have with this is, regardless of 
intention, "RFC" essentially functions as IETF's imprimatur and brand.   
If in practice we had lots of parties publishing RFCs, even if they were 
of high quality, they would serve to dilute IETF's brand and effect, as 
well as promote confusion about which documents actually came from 
IETF.   Sure, there are independent stream documents now, but they're 
relatively few in number.

I do think there should be room for "dissenting voices" within IETF to 
publish informational documents alongside IETF RFCs, for much the same 
reason that dissenting judicial opinions are useful.   But I would hate 
to see large numbers of non-IETF RFCs.

Keith

---

From: Jari Arkko <[email-masked]>
Date: Mon, 15 Jul 2019 23:54:57 +0300

Re: state actors and their desire to control standards and other things.

Yes, of course, and when I said “stable” I didn’t mean that we shouldn’t watch out for potential disruptions coming from several possible angles.

E.g., potential efforts to influence or mandate specific standards, perhaps in the area of end-to-end security :-) Or the use operational obligations of various Internet services to random five eye nations in the other side of the world, but not naming any country by name :-) We do need to watch for this, and if needed, change what we do or react/join campaigns to help ensure the Internet works well. Where we can. IANA is just a small piece of that overall picture, but the IAB IANA program is there precisely to watch that situation carefully. IAB as a whole has also tracked and participated in some of the other discussions.

Jari

---

From: Michael Thornburgh <[email-masked]>
Date: Mon, 15 Jul 2019 20:56:16 +0000

i authored two RFCs that were independent submissions:

  RFC 7016 (AD-sponsored; not actually in the Independent Stream, but it should have been, and caused some rule changes subsequent to publication)
  RFC 7425 (actually in the Independent Stream because of those rule changes)

these RFCs document protocols that were in widespread use in the Internet and widely deployed, and the IETF and RFC Series was absolutely the right place for this documentation.

there are at least two other Adobe RTMFP protocol documents that i would like to publish someday (time and resources permitting), and there is no other place than the RFC Series that makes sense to publish them.

-michael thornburgh
________________________________________
From: ietf [[email-masked]] on behalf of Keith Moore [[email-masked]]
Sent: Monday, July 15, 2019 1:34 PM

[...]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Jul 2019 09:25:42 +1200

Thanks to everybody for the discussions. I agree with Jari, BTW, that the IANA arrangement is *currently* working well. But I'll quote myself: "Yet the world has moved on dramatically and the IETF is no longer operating in the environment for which its present arrangements were designed." Leif's point that "digital identitiy development moved away" is one example among many of how the Internet standards space is immensely more complex (and important) than it was 20+ years ago. I think the IETF needs to be modest about its own importance in this new world.

Regards
   Brian

On 16-Jul-19 08:54, Jari Arkko wrote:
> .

---

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Jul 2019 00:27:22 +0300

Leif,

> on /our/ terms.

I think you said to yourself, people sometimes like to have their own terms :-) Nothing wrong with that.

> Melissa has suggested IPR as one cause.

There are many needs, of course, and a million different desirable standards copyright and patent IPR regimes. In my experience, the IETF copyright and IPR model is relatively attractive. Watching organisations that interact with many standards and open source efforts, the attrition rate for some of the other models can be pretty high. So I personally wouldn’t worry too much about this aspect. But yes, for someone who has specific needs the match may not be there. Yet one needs some agreement on the operating principles, e.g., that documents are openly accessible, can be revised by anyone, etc. I think the IETF rules are a reasonable compromise and quite flexible.

> There are probably other reasons (discussion climate etc).

And that all also partly depends on what we are talking about, e.g., actual IETF work, independent submission outside the IETF, creating a new stream, etc. I do think discussion climate affects things though. And so do a number of other things, such as reputation for getting stuff done (which I think we at the IETF have), where the expertise and ownership is perceived to be, etc. But, if I have no linkage to the IETF sphere, it isn’t clear that I’d be looking to publish RFCs. It is the (broad) community that brings the value.

Jari

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 16 Jul 2019 04:15:19 +0000 (UTC)

Working well? The Titanic was on fire, and had been since before leaving dock.

 https://medium.com/s/story/the-titanic-was-on-fire-for-days-before-the-iceberg-hit-94fa26471dfa 

all was not well below decks, but that enhances the metaphor, no?

Lloyd Wood [email-masked] http://about.me/lloydwood

On Tuesday, 16 July 2019, 04:38:40 GMT+10, Phillip Hallam-Baker <[email-masked]> wrote: 

The problem I see is that we have a bunch of nation state actors who think they should have control over the development of Internet standards. And rightly or wrongly, some of those actors see IANA as a control point.

Of course it is easy to dismiss concerns of this type as fear mongering. I did note that not a single one of the people who accused me of fear mongering and attempting to distract with false accusations when I reported that the IRG attacked one of my then employer's affiliates almost a decade ago apologized or even admitted making an error when the attribution was confirmed by Google when they identified an attack on another CA that was actually successful.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 16 Jul 2019 10:54:27 +0200

> I think you said to yourself, people sometimes like to have their own terms :-) Nothing wrong with that.

Sure, unless our terms are more exacting than they have to be.

>> Melissa has suggested IPR as one cause.

sorry for misspelling your name Melinda

> There are many needs, of course, and a million different desirable standards copyright and patent IPR regimes. In my experience, the IETF copyright and IPR model is relatively attractive. Watching…

I totally get that and I personally agree. However for smaller companies
whose primary IPR assets is tied up in that one strategic standards
process, its probably not surprising that other IPR models seem very
attractive. In particular variations on the theme "everyone keep their
IPR, promise not to litigate and publish after SDO agrees on what the
standard is" has been pretty common.

	Cheers Leif

---

From: "Pete Resnick" <[email-masked]>
Date: Tue, 16 Jul 2019 12:28:24 -0500

On 16 Jul 2019, at 3:54, Leif Johansson wrote:

> ...for smaller companies

People tend to forget that you can pretty much do that IPR model in the 
IETF if you really want to.

pr
-- 
Pete Resnick http://www.episteme.net/
All connections to the world are tenuous at best

---

From: Leif Johansson <[email-masked]>
Date: Tue, 16 Jul 2019 21:02:59 +0200

Skickat från min iPhone

> 16 juli 2019 kl. 19:28 skrev Pete Resnick <[email-masked]>:
> 
> People tend to forget that you can pretty much do that IPR model in the IETF if you really want to.

Has anyone ever done so?

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 16 Jul 2019 15:10:52 -0400

> IETF if you really want to.

The PKCS standards were this way for a while, but I recently (last fe
years) assisted with transferring change control over.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Pete Resnick" <[email-masked]>
Date: Tue, 16 Jul 2019 14:52:59 -0500

> years) assisted with transferring change control over.

Well, I guess I should have been more precise: Patent IPR you can 
obviously retain and make a promise not to litigate; that's what the 
whole IPR disclosure process allows you to do, and it's done all of the 
time. Copyright IPR you do have to give up change control over if you 
want it to be on the standards track. PKCS had all of its issues over 
copyright IPR, not patent IPR, IIRC.

pr

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 16 Jul 2019 16:05:24 -0400

> copyright IPR, not patent IPR, IIRC.

Yes, I may have been reading to quickly.

-- 

Best regards,
Kathleen

---

From: Ted Hardie <[email-masked]>
Date: Mon, 22 Jul 2019 11:04:18 -0400

Hi John,

I've added the ietf list, since the issue you raised includes those who are
not attendees.

On Mon, Jul 22, 2019 at 10:18 AM John C Klensin <[email-masked]> wrote:

>
>
> --On Monday, July 22, 2019 08:48 -0400 Ted Hardie
> <[email-masked]> wrote:
>
> > Just to add to Brian's note, this is more than likely, as the
> > IAB is asking the community specific questions around how to
> > move forward.  The questions are in the IAB report to the
> > community (
> > https://www.iab.org/2019/07/18/iab-report-to-the-community-at-
> > ietf-105/); as that notes, Olaf Kolkman will also present a
> > review of the current RFC Editor model to help frame some of
> > the timing questions.
>
> Ted,
>
> I didn't see any substantive questions other than whether to
> appoint (acting?) RSE and then start thinking through the role
> or to try to just move forward with a selection process there.
> Were those the questions you had in mind.
>
>
The choice laid out in the IAB report is:  should we delay issuing an RFP
until community discussion on the RFC Editor model has moved further along,
or should we issue an RFP now?  The current model already gives an RSE
responsibility for evolution of the series, so recruiting one with a strong
early focus on the evolution of the model is within the current model.

The current SOW has been shared with the community to allow comment on it
to proceed in parallel, should the community not wish to delay issuing and
RFP.  The IAB's intent is to continue soliciting discussion on the larger
point at least through the time the SOW is under discussion.  Having a few
hundred people in a room does, of course give some opportunity to get the
discussion going, but it will not be the end of it.

> I am glad you said "asking the community" rather than "doing a
> survey", but some of the same issues apply.   As others have
> pointed out several times, the RFC Series (and hence the ISE)
> serve much of the broader Internet Community, not just the IETF.
> FWIW, one theory about the role of the IAB is that it is
> supposed to serve  the broader Internet community too although I
> think we sometimes loose sight of that (and the IEtF-centered
> selection process doesn't help).  At least without a great deal
> of caution, a survey to collect opinions is only as good as the
> population being asked and how well those who respond represent
> that population.  "Asking the community" isn't much better:
> unless the IAB is just interested in confirming what it already
> believes -- and I assume that is not the case-- the usefulness
> of "asking the community" is only as useful as the parts of the
> community you choose to ask and who answers and how.  In
> particular, if "ask the community" is really going to be "ask
> around the IETF", then those other parts of the Internet
> Community who benefit from the RFC Series are effectively
> disenfranchised.
>
>
I encourage you to share the question beyond the IETF and IRTF, and the IAB
would be happy to work with you or others on structuring the message,
should it need re-framing for those audiences.

Even within the communities we have already heard from, the breadth of
opinion of what to do from here is substantial.  The only universal is that
we all regret Heather's decision.  Beyond that, the range of ideas shared
with me has included:

* make this a NomCom appointed position
* make this an employee of the IETF LLC, who has no contract term
* make this position a long term contract, in a model similar to judicial
appointments
* merge this position with the ISE role to reinforce the need for technical
judgement
* eliminate this position entirely
* retain the position largely as described, but make the RSOC NomCom
appointed
* focus this position on libraries and publication venues and recruit with
that focus
* retain this position but remove the oversight of the RFC Production
Center and RFC Publisher (with many variants of what that means for other
relationships)
* retain this position but make it more junior and more overseen by
community members

I am pretty sure that this is only a selection of the ideas out there.
That breadth is part of why the choices we're asking about are only about
how to order the community discussion and the recruiting process; we are
sure that a larger community discussion is needed.

> I was very strongly reminded last Tuesday just how small of a
> fraction of the Internet community, even the portion of the
> community that is interested in the Internet's protocols or how
> they are applied in practice, IETF participants represent.  If
> the IETF (not just the RFE Series) are going to remain relevant,
> I think we need to pay significant attention to that.
>
> The other problem, as Brian, I, and others, have pointed out is
> that the RSE position is a very specialized job, one into which
> it would be no more reasonable to drop someone whose skill set
> is in network engineering than it would be to expect the
> managing editor of, say, a biochemistry journal to be able to
> step into the IAB or IETF Chair roles or even to start designing
> network protocols (unless he or she had considerable network
> engineering background and experience in addition to their
> biochemistry one).  I assume and hope that Olaf will explain
> that in more detail on Wednesday.
>
> I'd lay good odds that, before the recent discussions broke out,
> only a small fraction of IETF participants had given any real
> thought to the role of the RSE and that many were only vaguely
> aware that it existed.  If that awareness level has risen,
> perhaps that is a good consequence of this otherwise bad
> situation.

I appreciate the kindness in suggesting a silver lining here.

> However, it suggests that, at least in addition to
> asking the community, you should be seeking out people with real
> expertise and/or history and asking them rather than either
> assuming that advice can come from general asking of the
> community or that sufficient expertise in those matters exists
> within the IAB or the present RSOC.
>
>
I cannot tell you how may times I have missed Joyce's wise counsel in these
past weeks.  As the first person to be recruited to join Jon and the first
to succeed him, I have read and re-read her text in RFC 2555, along with
Jake's, Bob's, Steve's,  and Vint's.  But I think we are honestly at a
moment where we must both look back and look forward.  The ecosystem in
which this series came to be has changed and, as you note, the community
has grown well beyond the borders of the IETF's halls.  That has left me
grateful that Leslie in RFC 4844 and Olaf in RFC 6635 clearly envisioned
change:

  This document, and the resulting structures, will be modified as
   needed through normal procedures.  The RSE, and the IAB, through the
   RFC Oversight Committee (see Section 3.1
<https://tools.ietf.org/html/rfc6635#section-3.1>), will continue to
monitor
   discussions within the community about potential adjustments to the
   RFC Editor model and recognize that the process described in this
   document may need to be adjusted to align with any changes that
   result from such discussions; hence, the version number in the title.

While it is possible that the discussion will end with a long-term
retention of the current model, I must say that I honestly expect change.

best regards,

Ted Hardie

best,
>    john

---

From: Ted Hardie <[email-masked]>
Date: Mon, 22 Jul 2019 11:14:19 -0400

On Mon, Jul 22, 2019 at 11:04 AM Ted Hardie <[email-masked]> wrote:

>  That has left me grateful that Leslie in RFC 4844 and Olaf in RFC 6635
> clearly envisioned change:
>
>
It was pointed out to me offline that I left out Joel Halpern's role as
editor of RFC 6635 in making the statement above.  My apologies for the
ommission,

regards,

Ted