Subject: Re: [Rfced-future] The voices of stakeholders

From: Martin J. Dürst <[email-masked]>
Date: Tue, 2 Feb 2021 12:06:22 +0900

On 01/02/2021 06:53, Christian Huitema wrote:
> 
> On 1/31/2021 12:43 PM, S Moonesamy wrote:

>> The person who is better suited for that job is the RFC Series 
>> Editor.  It is unlikely that under-represented stakeholders would be 
>> regular participants of the group in which the decision is taken. 
> 
> 
> I don't think so. We have more or less agreed that this is a matter of 
> knowing who the RFC "consumers" are and understand what their unmet 
> needs might be. In a commercial business, that's a task for marketing 
> departments and business managers. If I look at past RSE hiring 
> processes, market research and business management were not high on the 
> list of hiring criteria. If I look at RFC 8728, I don't find any mention 
> of market studies, user panels and the like. Indeed, doing such studies 
> would be very hard when the budgeted workload is only "approximately 20 
> hrs per week". So, no, the RFC Series Editor is not the better suited 
> person for that job.

I fully agree that the RFC Series Editor (or what we're going to call 
them) isn't too suited for formal marketing research that takes a 
serious amount of time.

But I think the RFC Series Editor is important when it comes to the 
voice of the stakeholders, in particular the "silent consumers" of RFC. 
The stream managers' backgrounds to first approximations all come from 
the writing side of the process, at least originally more interested in 
getting a new protocol to paper than in whether the series reaches the 
readership at large in the right way and serves them well. On the way to 
becoming a stream manager, the perspective will change somewhat, but 
probably only somewhat. For the participants in the WG, on average they 
will be even closer to the writers' side.

The RFC Series Editor, if we find the right person, is by their 
expertise attuned to the needs of both readers and writers. Even if this 
goes only so far as to have "how does this affect our potential 
consumers" on a checklist.

Regards,   Martin.

B.T.W.: I also agree that it may not be the best idea to spend a ton of 
money on marketing research. If we didn't do the right thing for the 
past 50 years, the RFC series wouldn't be in the position that we are 
now, and if we move forward steadily (but not too fast), we should be 
able to stay where we are or improve.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 6 Feb 2021 16:18:11 +1100

My .02 -

I agree that the RSA/E would have some scope to do this. 

I don't think it should rest completely on their shoulders; our community may have diversity issues, but the folks here are somewhat representative of many of those who are the audience.

In particular, our documents are very often used by developers of implementations. Implementers do participate in the IETF (at least in some WGs), but they may hesitate to participate in our process-oriented discussions (whether they're about RFC formats or not) because of the overhead of wading in and the obscurity of how to do so. Improving both would go a long way towards getting good feedback from them.

Our documents are also used by non-developer organisations interested in the Internet; e.g., civil society advocates. Again, they have some voice in the IETF, and we should make sure to give them a path to being heard. Having a WG is a good first step; establishing newcomer-friendly policies, documentation and communication channels are excellent improvement. 

As part of that, I think the RSA/E should be explicitly responsible for updating the woefully out-of-date RFC Editor web site, and making it more user-oriented. However, that update should be guided and helped by the community.

Those improvements would also benefit "outside" parties who are impacted. Adrian, you mention regulators. Considering that they're already dealing with a wide variety of inputs, I strongly suspect that regulators will take documents in whatever form we publish them, and account for any unusual aspects when handling them. Taking their needs into account is good, but I doubt if we'll be able to establish concretely what those needs are, beyond very generic things (e.g., well-defined identifiers for document revisions). Of course, regulators are likely to have very specific needs or asks for what the documents *contain*, but that's not of concern in this discussion.

Cheers,

> On 30 Jan 2021, at 12:11 am, Adrian Farrel <[email-masked]> wrote:
> 
> Hi,
> 
> I've been chewing on this thought for a while and trying to keep up with the
> list (but please excuse me if this has come up and I missed it).
> 
> The thrust of Ekr's proposal (1/25) seems reasonable, but I have a concern
> about how we handle the people who might be considerably impacted by any
> changes the WG might come up with, but who are not present in the WG.
> 
> Now, I can usually get behind, "If you want to influence the work,
> participate in the work." That is certainly how we have operated in the
> IETF, and generally it gives good results for producing quality technical
> specifications. But I think that this WG might be in a slightly different
> space.
> 
> In practice, we are asking people who are consumers of RFCs to participate
> in the discussions about the publication format etc. when they might not
> even be aware that the forum exists, and might anyway be unaccustomed to
> this way of working. In some cases, the stakeholders might even be one step
> removed from the RFCs (for example, regulators who want to point at RFCs,
> but who do not actually implement or read them).
> 
> My concern is that one or two people turning up from these large but
> under-represented classes of stakeholder may be swamped by our normal "rough
> consensus" process. I am not saying that their voices will not be heard, nor
> that the correct mechanisms will not be used to consider their input. But I
> am worried that they will lack the experience and expertise to make their
> points stick in this WG, and that, if push comes to shove, their voice will
> be seen as a minority and they will be placed "in the rough".
> 
> Of course, the chairs of the WG will have a considerable responsibility to
> make sure that things go well for everyone, but in the end, they also call
> rough consensus. They are only advocates for participants in ensuring that
> their voice has the opportunity to be heard.
> 
> So my questions are: Who is the advocate for the under-represented
> stakeholders? Whose job is it to actively search out relevant opinions? Who
> has the role of champion for these groups of RFC consumers to make sure that
> the decisions the WG make do not negatively impact them?
> 
> Thanks,
> Adrian
> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 6 Feb 2021 12:26:06 -0000

I knew, I just knew it as I typed it, that if I gave an example of a class
of user that is not frequently present in our working meetings or on our
mailing lists, someone would choose to debate that example rather than the
wider topic.

Mark rightly notes that some non-developer organisations that consume RFCs
have some voice in the IETF. He also notes that the way we conduct business
may inhibit participation. And this cuts somewhat to my concern, but not
completely.

I am worried that the way we in the IETF build and assess consensus is not
well suited to making decisions about the RFC series in a "working group"
because such a group is likely to be heavily populated by just one section
of the community (the regular IETFer) so that any counter opinions (if,
indeed, they are expressed at all) will be considered minor voices or in the
rough.

So it is good to hear some thoughts that the RSA/E would have some
responsibility for considering other voices and bringing their needs and
aspirations to the table. But it doesn't cut much ice with me to hear that
"the folks here are somewhat representative of many of those who are the
audience", in fact it worries we somewhat because it sounds similar to the
way silent majorities are often excluded by those in power (I do not accuse
anyone here present of such an intention).

Now, suppose the RSA/E has the responsibility and expresses a concern to the
WG. I know we all like to think ourselves reasonable people, and I suppose
we like to hope that we will pass the baton on to similarly reasonable
people, but suppose that the WG pushes ahead anyway disregarding the RSA/E's
concerns? What then?

- Is the RSA/E in the approval group to let them know the problems?
- Can a stream manager block the change that is not a direct harm to their
stream?
- Can the RSA/E somehow make the WG think again?

Cheers,
Adrian

-----Original Message-----
From: Mark Nottingham <[email-masked]> 
Sent: 06 February 2021 05:18
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rfced-future] The voices of stakeholders

My .02 -

I don't think it should rest completely on their shoulders; our community
may have diversity issues, but the folks here are somewhat representative of
many of those who are the audience.

In particular, our documents are very often used by developers of
implementations. Implementers do participate in the IETF (at least in some
WGs), but they may hesitate to participate in our process-oriented
discussions (whether they're about RFC formats or not) because of the
overhead of wading in and the obscurity of how to do so. Improving both
would go a long way towards getting good feedback from them.

Our documents are also used by non-developer organisations interested in the
Internet; e.g., civil society advocates. Again, they have some voice in the
IETF, and we should make sure to give them a path to being heard. Having a
WG is a good first step; establishing newcomer-friendly policies,
documentation and communication channels are excellent improvement. 

As part of that, I think the RSA/E should be explicitly responsible for
updating the woefully out-of-date RFC Editor web site, and making it more
user-oriented. However, that update should be guided and helped by the
community.

Those improvements would also benefit "outside" parties who are impacted.
Adrian, you mention regulators. Considering that they're already dealing
with a wide variety of inputs, I strongly suspect that regulators will take
documents in whatever form we publish them, and account for any unusual
aspects when handling them. Taking their needs into account is good, but I
doubt if we'll be able to establish concretely what those needs are, beyond
very generic things (e.g., well-defined identifiers for document revisions).
Of course, regulators are likely to have very specific needs or asks for
what the documents *contain*, but that's not of concern in this discussion.

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 7 Feb 2021 09:42:46 +1300

On 07-Feb-21 01:26, Adrian Farrel wrote:
...
> - Is the RSA/E in the approval group to let them know the problems?

I consider that to be essential. The stream managers are not omniscient.

> - Can a stream manager block the change that is not a direct harm to their

Yes. Especially if they think it is harmful to the series as a whole.

> - Can the RSA/E somehow make the WG think again?

Yes, if (and only if) the RSA/E can also prevent consensus in the approval group. But that's a "reserve power" that will never be needed if the WG functions as it's supposed to, which includes listening to the RSA/E.

   Brian

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 08 Feb 2021 11:14:08 +1100

On Sat, Feb 6, 2021, at 23:26, Adrian Farrel wrote:
> silent majorities are often excluded by those in power (I do not accuse

I find myself really liking the turn this discussion took.  That is, I like that we are explicitly considering the biases inherent in the designs we're considering and how to counteract them.

> WG. 

This my be my own lack of knowledge, but I'm hearing an assumption here, and I want to repeat what I'm hearing out loud to see if it makes sense to others.  It doesn't add up for me.

Are we assuming that the RSA/E has expertise in outreach to these diverse communities of interest?

Is this something that expertise in technical publication naturally comes with?  Which community or communities are then naturally represented?

Effective representation is something we struggle with everywhere.  But I can give an example from an adjacent community.  When we discuss whether web API Foo is good for the web, one of the questions we try to understand is whether the web developer community would benefit.  (Even there, we routinely fail to capture the diversity of that community, usually only getting input from large sites.)  But browser-makers in particular do spend non-trivial time and effort in gathering this input, and we also benefit from the experience of people in that community who aren't beholden to a browser-maker also.  But we do not assume that those people also represent the interests of communities in which they have not spent that time; though these are paid professionals with deep expertise, that expertise is narrow.  And the conclusions reached on the basis of web developer feedback can, on some matters, demonstrate a bias against other stakeholder interests (certain user communities, for instance).

In the IETF, we have experience with people connected to various communities that interact with the work we do.  People who implement, deploy, operate, purchase, and so forth.  As Mark points out, we are now lucky enough to sometimes have people participate from communities that study the effect of our decisions on people and societies.  But my experience is that the community of interest speaking is generally understood, usually as a result of getting to know the person speaking a little.

Of course no single person speaks for any community because no community is ever so uniform as to have precisely one position on just about any subject.  And any who claim to speak for a community can only do so through the filter of their own biases.  Again, getting to know someone to better understand those biases is also part of how we manage that.

I use the long anecdote (rant?) to highlight that if we are looking for someone to convey a particular viewpoint, we need to understand what we're looking for.  If publication expertise is truly alien to us engineer-y folks, I don't think that we have much hope of doing anything except invest the RSA/E with power that leaves the series at the mercy of the LLC hiring process.  But, like the lawyer example, I think that we can learn to recognize the shape of our lack of knowledge.  To do that, maybe someone can define the undefinable and tell me which community we might expect a publication expert to be able to represent.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 7 Feb 2021 19:23:50 -0500

I do not think that a technical publication expert can inherently 
represent the broad range of our external communities.

There are however two relevant dimensions.
First, much of senior technical publishing does involve making sure the 
constituent communities are heard from.   So while not an inherent 
expertise, it is a relevant expertise.
Second, we can write down (as we have in the past) that it is part of 
the job.  During previous searches for related positions, skill / 
experience / ability to provide that dimension was one of the thing that 
was asked about / considered during the selection.  (Whether we did the 
job right is a different question.)  Deciding what we want and including 
it the search criteria seems rather necessary.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 8 Feb 2021 13:29:41 +1300

> Are we assuming that the RSA/E has expertise in outreach to these diverse communities of interest?

I don't think so. I think we are saying that *somebody* needs to be tagged with responsibility for that topic, and unless we proposed to hire a Communications Director for the RFC Series, the RSA/E is the obvious person to tag.
 
> Is this something that expertise in technical publication naturally comes with?

Not necessarily, although these days a lot of people are graduating with Communications-related degrees but ending up in technical or specialist writing. So I wouldn't exclude somebody having both these skill sets. But I don't think we're saying the RSA/E will *do* the outreach, but that they will get it done.

> Which community or communities are then naturally represented?

Isn't that very much TBD and why we need this on somebody's to-do list? If we had a factual list of who reads or otherwise depends on RFCs, we'd be halfway there already. In fact, until we have that list, I don't think we can tackle your question below.

Regards
   Brian C

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 8 Feb 2021 00:52:15 +0000

Apologies for top posting:

Martin,

I think bringing in "representation" isn't a good idea. It's
not a thing we do, nor process well. I think the main reason
for that (and a good reason) is that we don't have an
elector's register nor members.

I do agree with Brian that having the RSE be the person who
we hope can best consider viewpoints and interests (related
to the RFC series) that are not otherwise represented is a
good idea. But that doesn't mean the RSE is "representing"
anyone, nor IMO should it.

Cheers,
S.

On 08/02/2021 00:14, Martin Thomson wrote:
>> silent majorities are often excluded by those in power (I do not
>> accuse anyone here present of such an intention).
> 
> I find myself really liking the turn this discussion took.  That is,
> I like that we are explicitly considering the biases inherent in the
> designs we're considering and how to counteract them.
> 
>> Now, suppose the RSA/E has the responsibility and expresses a
>> concern to the WG.
> 
> This my be my own lack of knowledge, but I'm hearing an assumption
> here, and I want to repeat what I'm hearing out loud to see if it
> makes sense to others.  It doesn't add up for me.
> 
> Is this something that expertise in technical publication naturally
> comes with?  Which community or communities are then naturally
> represented?
> 
> Effective representation is something we struggle with everywhere.
> But I can give an example from an adjacent community.  When we
> discuss whether web API Foo is good for the web, one of the questions
> we try to understand is whether the web developer community would
> benefit.  (Even there, we routinely fail to capture the diversity of
> that community, usually only getting input from large sites.)  But
> browser-makers in particular do spend non-trivial time and effort in
> gathering this input, and we also benefit from the experience of
> people in that community who aren't beholden to a browser-maker also.
> But we do not assume that those people also represent the interests
> of communities in which they have not spent that time; though these
> are paid professionals with deep expertise, that expertise is narrow.
> And the conclusions reached on the basis of web developer feedback
> can, on some matters, demonstrate a bias against other stakeholder
> interests (certain user communities, for instance ).
> 
> In the IETF, we have experience with people connected to various
> communities that interact with the work we do.  People who implement,
> deploy, operate, purchase, and so forth.  As Mark points out, we are
> now lucky enough to sometimes have people participate from
> communities that study the effect of our decisions on people and
> societies.  But my experience is that the community of interest
> speaking is generally understood, usually as a result of getting to
> know the person speaking a little.
> 
> Of course no single person speaks for any community because no
> community is ever so uniform as to have precisely one position on
> just about any subject.  And any who claim to speak for a community
> can only do so through the filter of their own biases.  Again,
> getting to know someone to better understand those biases is also
> part of how we manage that.
> 
> I use the long anecdote (rant?) to highlight that if we are looking
> for someone to convey a particular viewpoint, we need to understand
> what we're looking for.  If publication expertise is truly alien to
> us engineer-y folks, I don't think that we have much hope of doing
> anything except invest the RSA/E with power that leaves the series at
> the mercy of the LLC hiring process.  But, like the lawyer example, I
> think that we can learn to recognize the shape of our lack of
> knowledge.  To do that, maybe someone can define the undefinable and
> tell me which community we might expect a publication expert to be
> able to represent.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 8 Feb 2021 09:26:04 -0000

> Are we assuming that the RSA/E has expertise in outreach to these diverse
communities of interest?

I think Joel captured most of the important points.

But:
This is not solely about outreach, it is also about experience in
publication for diverse communities.

And:
It is also also about who the "champion" will be when it is not the primary
interest of any of the other parties (WG, approval group) to know or care
about the diverse communities. Who is the stuckee for this?

Adrian

---

From: Sarah Banks <[email-masked]>
Date: Mon, 8 Feb 2021 11:50:32 -0800

Hi,
	A big +1 to Joel's points, and I'd like to "yes, and", and address a point from Martin's last paragraph. I've never viewed the RSE as a role we were "at the mercy" of; no more so than we are at the mercy of the IAB, for example. Given the actions that have occurred over the last 2 years, I very much support the idea of having the independent RSE role, with less of a touch from the IAB. I also agree with Martin that we need to define what we want, and I think we've learned from the first time we documented the job description of the RSE. We can - and should - do better and improve that description this time through. My hope is, if we agree in the RSE role as an independent, publishing-expertise-savvy role, that we'll crisply define the skills we need, the skills we want, and outline the job description accordingly.

Thanks,
Sarah

> On Feb 7, 2021, at 4:23 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> I do not think that a technical publication expert can inherently represent the broad range of our external communities.
> 
> First, much of senior technical publishing does involve making sure the constituent communities are heard from.   So while not an inherent expertise, it is a relevant expertise.
> Second, we can write down (as we have in the past) that it is part of the job.  During previous searches for related positions, skill / experience / ability to provide that dimension was one of the thing that was asked about / considered during the selection.  (Whether we did the job right is a different question.)  Deciding what we want and including it the search criteria seems rather necessary.
> 
> Yours,
> Joel
> 
>> Effective representation is something we struggle with everywhere.  But I can give an example from an adjacent community.  When we discuss whether web API Foo is good for the web, one of the questions we try to understand is whether the web developer community would benefit.  (Even there, we routinely fail to capture the diversity of that community, usually only getting input from large sites.)  But browser-makers in particular do spend non-trivial time and effort in gathering this input, and we also benefit from the experience of people in that community who aren't beholden to a browser-maker also.  But we do not assume that those people also represent the interests of communities in which they have not spent that time; though these are paid professionals with deep expertise, that expertise is narrow.  And the conclusions reached on the basis of web developer feedback can, on some matters, demonstrate a bias against other stakeholder interests (certain user communities, for instan
> ce
>>  ).

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 8 Feb 2021 14:24:30 -0700

[ no hats ]

> represent the broad range of our external communities.

There might be value in trying to describe this "broad range". (Pardon
me if that's been done already.)

Earlier in the thread, Mark Nottingham said: "our documents are very
often used by developers of implementations."

It strikes me that this is the *primary* use of our documents.

Although this perspective might be seen as simplistic, I've always felt
that my core task as an RFC author is to help design a sensible protocol
and document it as clearly and accurately as possible so that engineers
can write interoperable code.

This might imply a different vision of "technical publishing" than what
might come to mind if we're comparing the RFC series to, say, Physical
Review or The Lancet.

Yes, we have are other "customers" - civil society groups, regulators,
patent lawyers, historians and sociologists of technology, etc. - but if
engineers weren't using RFCs to write code and deploy services used by
billions of people then it seems to me that very few of these other
customers would care about the RFC series.

Peter

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 9 Feb 2021 10:37:41 +1300

> It strikes me that this is the *primary* use of our documents.

I'd put that equal first with use by operators. In fact, I suspect that
operators outnumber developers.

Otherwise, you're correct (but add educators and researchers). However
I think we want all of them inside the big tent, don't we?

   Brian

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 8 Feb 2021 21:59:39 -0000

Hi Peter,

At the risk of being accused of pedantry...

> can write interoperable code.

Tell us about RFC 4417.
And RFC 6702.
RFC 7259 gives an interesting slant.

Etc. 😊

Perhaps we also need to be a bit careful when we say, "use of *our* documents." Who are the "we" that we refer to?

Anyway, the point here is not that you and Brian are wrong about the primary uses, but that we don't want to sacrifice other uses accidentally along the way.

Cheers,
Adrian

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 8 Feb 2021 15:24:19 -0700

> operators outnumber developers.

Likely so. However, operators offer services based on the code that
developers write, so I think of these as one bundle.

> Otherwise, you're correct (but add educators and researchers).

See my comment below about people wouldn't care a whit about the RFC
series if billions of developers and operators didn't have running code.

> However

Although I can't object to a big tent, I think it would be helpful for
us to think clearly about these different communities of interest so
that we can prioritize their respective needs.

Peter

---

From: Ted Lemon <[email-masked]>
Date: Mon, 8 Feb 2021 17:43:47 -0500

> It strikes me that this is the *primary* use of our documents.

I’ve read documents like that too.

We should probably do better.

It’s not at all unusual for a document to come with so little context that someone other than an SME implementor would have trouble getting anything useful out of it. Which would be fine, if there were some other document that explained what other users of the document needed to know. Sometimes there is—sometimes we have operational documents, for example. But it’s not uncommon for “how this works” to either be completely absent, or else only available as a result of an SME-level survey of a bunch of documents. The thing that’s missing is that if only SMEs can understand the document, then the only way to get new SMEs is through a lineage of existing SMEs who train them. Hopefully the reason this is a problem is obvious.

Now, whether you agree with the assertion I’m making here or not, the reason I bring it up in this context is that your original assertion, Peter, seems to substantiate the existence of unrepresented document users. Perhaps it’s not our job (or the RSE’s) to see to it that they are represented. However, looking back over my checkered career as an IETF participant, there are quite a few documents that, if I had it to do over again, I would have insisted ought to do a better job of explaining to a new reader what the theory of operation of the protocol was, before describing the implementation details. So I would not object to some pushback when the RSE encounters a document like this. The documents I have in mind are actually documents I should have pushed back on as an AD, but so maybe the answer isn’t to have the RSE fill this role, but it’s definitely a role that I think someone should be filling.

Bear in mind that if there’s an understanding that a poorly explained protocol spec would get pushback, that’s going to motivate the working group to do a better job prior to submission, so in principle the RSE and/or ADs don't actually have to do anything other than look stern. But the threat of pushback has to be there.

---

From: Jay Daley <[email-masked]>
Date: Tue, 9 Feb 2021 11:53:07 +1300

From the very informative discussion so far I understand why the RSE/A should be “a” representative of the RFC reader community but not why they should be the “primary“ representative.  The main reason I’ve heard so far is “there’s a gap and they are the natural person to fill it” but from my relatively naive perspective it seems as if the stream managers should have that role for their readers because they control what is read and they need the direct feedback loop.  What the streams won’t have and what the RSE/A therefore appears to have is a more generic and broader overview in line with their expertise e.g. machine readability, journal/library referencing and so on.  

Or to put this another way, it reads as if some want the RSE/A to have a product manager role, which on the surface seems to fit but that seems to deliberately disconnect the streams from their part in that.  Have I understood this correctly?

-- 
Jay Daley
IETF Executive Director

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 8 Feb 2021 22:56:01 +0000

Hiya,

On 08/02/2021 22:24, Peter Saint-Andre wrote:
> Although I can't object to a big tent, I think it would be helpful
> for us to think clearly about these different communities of interest
> so that we can prioritize their respective needs.

I think I agree with you both - that developers and then
those deploying are our primary audience and that there
are others too, as Brian said.

One thing though: IMO when we say "developers" there, I
interpret that to not only mean developers following today's
fashions, but also those who might follow future fashions,
to the extent those be reasonably considered. To put that
another way, I think RFCs should probably never be exactly
what any one developer wants at a given moment in time, as
RFCs need to be more generic and longer-lasting.

Cheers,
S.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 8 Feb 2021 22:57:46 -0000

Jay,

It may be as simple as the distinction between content and form.

The stream manager knows (or should know) how the content can be useful to the consumers. But it seems unlikely that the stream manager understands the ways in which the content (i.e., the documents) will be stored, accessed, read, and otherwise used by a disparate community.

Cheers,

Adrian

From: Rfced-future <[email-masked]> On Behalf Of Jay Daley
Sent: 08 February 2021 22:53
To: [email-masked]
Subject: Re: [Rfced-future] Communities and representation (was Re: The voices of stakeholders)

-- 

Jay Daley
IETF Executive Director

---

From: Jay Daley <[email-masked]>
Date: Tue, 9 Feb 2021 11:58:54 +1300

> On 9/02/2021, at 11:57 AM, Adrian Farrel <[email-masked]> wrote:
> 
> 
> Jay,
>  

I like that distinction.  Thanks.

-- 
Jay Daley
IETF Executive Director

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 8 Feb 2021 23:05:32 +0000

Hiya,

On 08/02/2021 22:53, Jay Daley wrote:
> from my relatively naive perspective it seems as if the stream
> managers should have that role for their readers because they control
> what is read and they need the direct feedback loop
I don't disagree, but I would note that the intricacies of
RFCs are not really the primary job of the stream managers -
maybe the ISE is closest, but the IETF, IAB and IRTF stream
managers have I think mostly so far always been people who
are pretty busy elsewhere.

So I think there're also pragmatic reasons to plump for the
RSE as this "gap filler" - if one sees this as related to
the question as to why/how the series has (so far) been so
long-lived but has remained useful.

Cheers,
S.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 8 Feb 2021 16:07:08 -0700

>> can write interoperable code.

Good old 4417. Documentation of an IAB messaging workshop, cited by no
other RFCs, and perhaps deservedly disappeared down the memory hole.

> And RFC 6702.

We do need to document our own procedures, don't we? Proving the rule
(in the original sense), this is more documentation, albeit internally
focused.

> RFC 7259 gives an interesting slant.

A cute experiment, never widely implemented.

> Perhaps we also need to be a bit careful when we say, "use of *our* documents." Who are the "we" that we refer to?

Those of us writing the documents, commenting on them, implementing
them, etc.

> Anyway, the point here is not that you and Brian are wrong about the primary uses, but that we don't want to sacrifice other uses accidentally along the way.

For sure. I'm not suggesting that we sacrifice anyone's interests, only
first of all that we understand them. :-) However, I would suggest that
at some point we will need to weight them because not everyone's
interests can be the top priority.

Peter

---

From: Jay Daley <[email-masked]>
Date: Tue, 9 Feb 2021 12:20:52 +1300

> On 9/02/2021, at 12:05 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

Thinking aloud now, but I wonder if any thought has been given to a new structure designed to create that feedback loop more directly.  For example, something as simple as a feedback form accessible from each RFC page would be a good start.  I imagine it would be used most when a new RFC is published.

Jay

-- 
Jay Daley
IETF Executive Director

> 
> Cheers,
> S.
> <OpenPGP_0x5AB2FAF17B172BEA.asc>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 8 Feb 2021 18:21:07 -0500

Peter, that does not match my understanding or observations; many 
operators read our RFCs, and attempt to get what they want from vendors 
(as they should).  How effective they are at it varies.

Also, other SDOs use our RFCs to build solution profiles that are used 
by Operators.

Product line managers read (or at least try to decipher) our RFCs to try 
to drive what will go into products.

And the list goes on.

While implementors are an important constituency, they are by no means 
the only one.  And I doubt that they constitute even 50% of the readership.

Yours,
Joel

---

From: Michael StJohns <[email-masked]>
Date: Mon, 8 Feb 2021 19:13:01 -0500

On 2/8/2021 6:20 PM, Jay Daley wrote:
> Thinking aloud now, but I wonder if any thought has been given to a 
> new structure designed to create that feedback loop more directly. 
>  For example, something as simple as a feedback form accessible from 
> each RFC page would be a good start.  I imagine it would be used most 
> when a new RFC is published.
>
> Jay

Surveys are useful when tightly targeted and there's an immediate use of 
their outputs.  In the case of just published RFC's, that use may be 
years or decades in the future when the next version of the document 
starts to wend its way through the IETF.   Every question you might ask 
on the survey would have hopefully been asked during the documents 
development or during the approval process.

So - I can't imagine this tool to be very useful.  Or am I misguessing 
what types of questions you had in mind asking?

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 9 Feb 2021 13:52:49 +1300

> Thinking aloud now, but I wonder if any thought has been given to a new structure designed to create that feedback loop more directly.  For example, something as simple as a feedback form accessibl…

The things are called "Request for *Comments*" but the boilerplate doesn't even hint where Jane Doe could send her comments. People with a bit of esoteric knowledge know how to submit errata, and people could send email to the authors (except that for older RFCs, the addresses listed are often obsolete). So yes, something should probably be done in this area. But it has to be more meaningful than https://tinyurl.com/2xl6fys2

     Brian

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 08 Feb 2021 16:56:46 -0800

> operators outnumber developers.

It's a fun game to play:  let's create a list of people that might want
to read (and understand) our RFCs:

   Grandma
   Kernel Protocol Software Engineers

Then we can fill it in and draw a line somewhere for 'who our community
is?' and hope it's the same line as 'who we are writing these things for?'
and hope it's the same line as 'who's opinions do we care about?'.

   Average computer owners
   Savvy computer owners
   Layers
   CEOs
   CTOs
   Product managers (thanks Joel)
   Commercial and Government procurement managers 
   Open source in their spare time authors
   Commercial Application developers 
   Network operators
   Machine Language researchers
   Security researchers
   Networking researchers
   Networking equipment engineers   
   Kernel Protocol Software Engineers

I'm sure the list is much longer.  I'm sure others would sort it
differently.  But in the end, isn't there a line somewhere, or a rating
to apply per line for "how much we optimize our documents for that set
of people"?  And the question then becomes "how do we get feedback from
them?" and "does the RSA/E need to have skills to and the requirements
to conduct that study?"

(I'll note that if the answer to the last question is "no" then maybe
the topic is out of scope for the near term at least?)

-- 
Wes Hardaker
USC/ISI

---

From: Christian Huitema <[email-masked]>
Date: Mon, 8 Feb 2021 16:57:54 -0800

> long-lived but has remained useful. 

I think that Jay is making an important point: the reason we have the 
streams in the first place is because we want to provide useful content, 
which is very much the task of the stream managers or the organizations 
that they represent. To answer Stephen's question, I think the main 
reason why "the series has (so far) been so
long-lived but has remained useful" is, because the IETF managed to 
produce specifications that are useful for the Internet. This is 
primarily a matter of producing good content. The form matters two, 
specifically the property that specifications are available to everybody 
without restrictions, and, for the continuity part, the property that 
the IETF publication are easily recognized as part of a long duration 
series. But if we do believe that this is primarily about "producing the 
right content", then the responsibility of verifying that belong to the 
stream managers, not to a technical expert.

-- Christian Huitema

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 8 Feb 2021 20:21:00 -0500

I agree Christian that the content is primary.
But the point of this part of the process is about the form and clarity, 
not the technical substance.

We do not select people to be stream managers.  For the various roles 
from which stream managers come (except maybe the ISE) technical 
publication expertise, understanding of the impact of presentation form, 
and even receptivity to the many outside communities that use our 
documents are not high on the list of criteria that the nomcom uses.
WWe can, and I think should, make sure those are included in the RSE/A 
selection criteria.  And then give them the participation and voice to 
go with that.

Yours,
Joel

---

From: Jay Daley <[email-masked]>
Date: Tue, 9 Feb 2021 15:26:18 +1300

> On 9/02/2021, at 1:13 PM, Michael StJohns <[email-masked]> wrote:
> 
> Surveys are useful when tightly targeted and there's an immediate use of their outputs.  In the case of just published RFC's, that use may be years or decades in the future when the next version of the document starts to wend its way through the IETF.   Every question you might ask on the survey would have hopefully been asked during the documents development or during the approval process.
> 
> So - I can't imagine this tool to be very useful.  Or am I misguessing what types of questions you had in mind asking?

The purpose would be to capture the views of those that were not involved in the production and hopefully not involved in the IETF - i.e. the extant user community that many have inferred exists.  I didn’t use the word survey because I would imagine that the main mechanism is free text comment with tighter questions to understand who is giving the feedback and a basic readability type score.

Jay

-- 
Jay Daley
IETF Executive Director

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 9 Feb 2021 02:38:14 +0000

Hiya,

On 09/02/2021 02:26, Jay Daley wrote:
> The purpose would be to capture the views of those that were not
> involved in the production and hopefully not involved in the IETF -
> i.e. the extant user community that many have inferred exists.  I
> didn’t use the word survey because I would imagine that the main
> mechanism is free text comment with tighter questions to understand
> who is giving the feedback and a basic readability type score.
Personally, I think ways to garner input and review of
published RFCs is a major missing mechanism. The errata
process as-is seems to me a very weak late 20th-C attempt at
that on which it really ought be easy to improve. And I'd say
a good RSE, with time and time-to-focus available, ought be
able to oversee a vast improvement on status quo.

I do think there's an editorial element to that - we already
see spam-errata fairly regularly, as well as random comments
on no-longer-interesting RFCs, so whatever better scheme
might be put in place will require judgement and management
as to proper disposition of comments. That couldn't and
shouldn't be done by an RSE in isolation, but managing it
seems to me to be a fine task for an RSE to me.

Cheers,
S.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 9 Feb 2021 18:00:46 +1100

Hi Adrian,

> On 6 Feb 2021, at 11:26 pm, Adrian Farrel <[email-masked]> wrote:
> 

This is in no way unique to the governance of the RFC Series. IETF WGs make decisions all the time about things that affect folks that don't show up, or are only partially represented by those in the room. Recently, I wrote an RFC about that, and how we should handle it.

As such, I remain unconvinced that the RFC Series is a special case that needs extraordinary processes or powers for a designated expert.

> people, but suppose that the WG pushes ahead anyway disregarding the RSA/E's

Then the consequences will be felt.

I am unwilling to bless someone as a monarch over the series just because something bad might happen one day, and we need someone to rescue us by telling us what to do. That much responsibility should not sit on one head, no matter what their heredity, credentials or provenance. We're currently trying to untangle such a position from the governance of the W3C, and it's a real bear. 

Better to stay with the well-worn path that the IETF has paved: create multiple layers of appeal that get more infrequently used and more deliberative as you work your way up, in the hope that time, distance and cooler heads will prevail. If the RSA/E gives good advice, it should be listened to.

Cheers,