Subject: [Rfced-future] Attempting to collect key points

From: Eliot Lear <[email-masked]>
Date: Thu, 2 Apr 2020 22:26:00 +0200

If anyone wants to see the notes I’m taking, and those notes may be entirely too abbreviated or just plain wrong, you can see them here <https://github.com/intarchboard/rfced-future/blob/master/PossibleGoalsandPointsMade.md>.  I’m a few hours behind at the moment.

---

From: Larry Masinter <[email-masked]>
Date: Thu, 2 Apr 2020 22:37:39 -0700

Let me try again

The point of the AUTH48 example was as an area where user’s expectation of the RFC editor often are greater than the RFC editor job description. Either change the process or add to the job description.

It was intended as a “small” problem statement under the proposed agenda of first step 1 listing things that need to be fixed.

Suggested reading “publishing workflow” and “galley proof”

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 5 Apr 2020 11:10:19 +1200

Hi Eliot,

In your notes I see "What happens to the series if the IETF disappears?"

We could also ask: What happens to the IETF if the series disappears?

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 5 Apr 2020 11:12:10 +1200

Another point that I think has been mentioned: What is the community of interest for this discussion? More than IETF+IRTF, but how much more? Can we even define it?

Regards
   Brian

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 5 Apr 2020 02:02:19 +0100

On 05/04/2020 00:12, Brian E Carpenter wrote:
> Another point that I think has been mentioned: What is the community
> of interest for this discussion? More than IETF+IRTF, but how much
> more? Can we even define it?

So I know that others (who I respect) disagree with me,
but I'm always puzzled as to why this is a puzzle: the
community of interest for RFCs seems to me like it has
to be the set of people who read RFCs.

The community of interest for this exercise then has to
be the subset of that set of people who decide to involve
themselves actively, here on this list.

That does mean those of us involved, esp. those of us who
think we'd benefit from broader participation, have an onus
on us to try reach out to other RFC readers and encourage
them to be more involved, but I honestly don't see that any
of that is complicated, nor that there's any other
alternative.

S.

> Regards Brian
>> If anyone wants to see the notes I’m taking, and those notes may be
>> entirely too abbreviated or just plain wrong, you can see them here
>> <https://github.com/intarchboard/rfced-future/blob/master/PossibleGoalsandPointsMade.md>.
>> I’m a few hours behind at the moment.
>> 
>

---

From: "John Levine" <[email-masked]>
Date: 4 Apr 2020 21:44:23 -0400

>We could also ask: What happens to the IETF if the series disappears?

In view of the way the funding works, I think the former question is a
lot more interesting.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 5 Apr 2020 13:53:26 +1200

> In view of the way the funding works, I think the former question is a

Probably, but if we're doing any kind of scenario analysis, then istm that
both questions arise.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 5 Apr 2020 14:01:27 +1200

> the

I tend to agree, and if we want the opinion of RFC consumers, not
just producers, we might want to consider how to reach them.

There are certainly a lot of people who read RFCs that are not on
any of our regular mailing lists. (I see that the RFC Editor has 
RSS and Atom feeds for recently published RFCs, but I have no idea
how many people use them.)

Regards
   Brian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 5 Apr 2020 09:53:35 +0100

Thoughts:

Should this program be advertised in some way on the rfc-editor.org web pages?

Should it be promoted through the IETF social media and press presences?

But then, is the purpose of this program to bring in as many people as possible at this early stage, or is it to have a focused sub-group of interested parties to come up with a working proposal that can then be debated more widely by the entire community of interested parties?

I have only questions, not answers.

Adrian
-----Original Message-----
From: Rfced-future <[email-masked]> On Behalf Of Brian E Carpenter
Sent: 05 April 2020 03:01
To: Stephen Farrell <[email-masked]>; Eliot Lear <[email-masked]>; [email-masked]
Subject: Re: [Rfced-future] Community [Re: Attempting to collect key points]

Regards
   Brian

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

---

From: Eliot Lear <[email-masked]>
Date: Sun, 5 Apr 2020 14:46:44 +0200

> On 5 Apr 2020, at 01:10, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi Eliot,
> 

Now that’s on the list as well. 

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Sun, 5 Apr 2020 14:52:52 +0200

Hi Adrian

> On 5 Apr 2020, at 10:53, Adrian Farrel <[email-masked]> wrote:
> 
> Thoughts:
> 

Good questions, and I like Stephen’s answer, but let me ask the question this way:

Do we want to ask the IAB to send liaisons to various places who we know use our output?  If we are discussing the form and future of the series itself, then I would think we’d want a broad approach.  If we are talking about the internal management and oversight of the role, and putting aside the form and future of the series, then I don’t see the benefit.  These are not binary. There’s some crossover.

Eliot

---

From: Larry Masinter <[email-masked]>
Date: Sun, 5 Apr 2020 12:16:40 -0700

The community of interest is NOT "those who read RFCs" and trying to do surveys of them a bad idea.
The community of interest is NOT "anyone who cares enough to sign up here" although that might be convenient.

RFCs and the RFC series and streams have a role to play in assuring the robustness of the Internet.
Reliability (especially in an always-update-software world) means avoiding vendor-lock-in
as a single point of failure. The RFCs have a requirement to be somehow useful to the
community involved in the process of specifying, producing, debugging, operating,
documenting, etc multiple independent interoperable implementations.

As the WebRTC discussion on the IETF list seems to indicate, there are differences of
perspective around the processes of IETF vs WHATWG/W3C. Standards-track with
internet drafts, a document editor producing unmodifiable RFCs followed by errata
and updates on the one hand, and "Living Standards" with GitHub issues and forking 
with pull requests on the other, and a more modular way of specifying and 
approving extensions based on implementation.

What I don't understand is how much in that difference in perspective is due to the
layer of the stack and how much is just old vs. newer.
--
https://LarryMasinter.net 
https://going-remote.info

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 5 Apr 2020 20:41:59 +0100

Hiya,

On 05/04/2020 20:16, Larry Masinter wrote:
> The community of interest is NOT "those who read RFCs" and trying to
> do surveys of them a bad idea. The community of interest is NOT
> "anyone who cares enough to sign up here" although that might be
> convenient.
> 
> RFCs and the RFC series and streams have a role to play in assuring
> the robustness of the Internet. Reliability (especially in an
> always-update-software world) means avoiding vendor-lock-in as a
> single point of failure. The RFCs have a requirement to be somehow
> useful to the community involved in the process of specifying,
> producing, debugging, operating, documenting, etc multiple
> independent interoperable implementations.

So I can see how one might conclude that, but still
figure I prefer my definition:-)

The argument I'd make is to point out that the community of
interest for RFCs is not the community of interest for the
set of technologies described in RFCs. For example, I'd
still care about https even if the specification for
https was written in Ogham ([1] basically - scratch marks
on standing stores:-)

If you accepted that argument then I think you might
conclude as I've done. (I'm not saying you will, I'm
only saying you might:-)

Cheers,
S.

[1] https://en.wikipedia.org/wiki/Ogham

> 
> As the WebRTC discussion on the IETF list seems to indicate, there
> are differences of perspective around the processes of IETF vs
> WHATWG/W3C. Standards-track with internet drafts, a document editor
> producing unmodifiable RFCs followed by errata and updates on the one
> hand, and "Living Standards" with GitHub issues and forking with pull
> requests on the other, and a more modular way of specifying and 
> What I don't understand is how much in that difference in perspective
> is due to the layer of the stack and how much is just old vs. newer. 
> -- https://LarryMasinter.net https://going-remote.info
> 
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 6 Apr 2020 08:31:31 +1200

> Now that’s on the list as well. 

Thanks. I'm not, by the way, suggesting that this is a *likely* scenario.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 6 Apr 2020 11:18:55 +1200

>> independent interoperable implementations.

Yes. I think that's well proxied by "the people who read RFCs",
so I don't understand Larry's remark. The people who read RFCs
include coders, testers, product managers, network designers,
operators, and sometimes people writing RFPs. And certainly,
people active in other SDOs.

   Brian

---

From: Larry Masinter <[email-masked]>
Date: Sun, 5 Apr 2020 23:54:53 -0700

> Yes. I think that's well proxied by "the people who read RFCs", so I don't
> understand Larry's remark. The people who read RFCs include coders,
> testers, product managers, network designers, operators, and sometimes
> people writing RFPs. And certainly, people active in other SDOs.

Why do RFC's have Editors or Authors? Why not let the heatmap of the
GitHub repo of the spec stand in? It would reduce the problems
of Unicode author's names and more than 6 names. But then
it would reduce the effectiveness of author-recruiting among those
seeking tenure might want to claim an RFC counts as a peer-reviewed
article. The readers are the tenure committee. Are they part of the
required community of interest for the RFC series?

being useful to tenure track academics was a reason given for adding
DOIs to RFCs. But if you have different RFCs with the same number,
Don't they need different DOIs.
--
https://LarryMasinter.net
https://going-remote.info

---

From: Joseph Touch <[email-masked]>
Date: Mon, 6 Apr 2020 08:07:43 -0700

> On Apr 5, 2020, at 11:54 PM, Larry Masinter <[email-masked]> wrote:
> 
> GitHub repo of the spec stand in?

Because authorship is - or should be - determined by a policy that can be complex and cannot be so trivially automated.

Although USC is not a paragon of ethics by any sort, it did have a reasonable policy on this matter that helps illustrate why it’s not merely a matter of who contributes text: https://research.usc.edu/files/2011/07/URC_on_Authorship_and_Attribution_10.20111.pdf <https://research.usc.edu/files/2011/07/URC_on_Authorship_and_Attribution_10.20111.pdf>

And yes, although this matters more for bean-counting tenure committees and deans - who paradoxically use the kind of blind automation you suggest above - it’s no less relevant here in the IETF. The Author Overload policy only exacerbates this effect. 

Joe

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 Apr 2020 12:19:59 -0400

Joe,

While I agree with your comments below, another piece of the
answer is to have some human to whom questions can be addressed.
That use of author listings with RFCs of course predates Jon
Postel's taking on the RFC Editor role -- the days when "Request
for Comments" was an accurate description, not just a name.  Of
course, for a Standards Track document, "ask the author" may be
the wrong answer and it should perhaps be "ask the IETF somehow"
(see below).  It also interacts with our AUTH48 process because
the "author" is the key person who needs to sign off on the
technical content being unchanged and the editorial content and
presentation being satisfactory.  Neither is actually a great
fit for Standards Track documents [1].  It is not an accident
that, in most other SDOs, the documents "belong to" the
organization and its secretariat (including editorial stuff) and
the author is the SDO itself and not some individual.  Even the
person who held the pen during document development may be
acknowledged as editor somewhere, but is never listed as author
or editor when the document is cited.  That is very much tied to
why editing prior to voting (even if more editing needs to be
done after voting and, often, the voting repeated) works for
them and would not work for us.

Especially for a Standards Track document whose predecessor I-Ds
underwent significant change as a WG struggled with the subject
matter, the question of academic credit really should be much
more complicated than the way we have been treating it because,
by the time the document is published, the "author(s)" may no
longer be the primary technical/professional contributor(s).

I think the question of whether we should re-think listing of
authors on some or all IETF Stream documents is an interesting
one.  I hope is it out of scope for this effort if only because
(i) as Larry's note, yours, this one, and a few others
illustrate, it is not a simple question and (ii) the discussion
would benefit from the experience of, and advice from, senior
publishing professionals, not us amateurs, (iii) it is
_probably_ an issue confined to that stream.

best,
   john

[1] And perhaps, with the recent change requiring community
consensus for all IETF Stream documents, for all documents
published in that stream... although I'm still not completely
clear whether that IETF consensus means "we agree that this
should be published" or "we agree with everything it says".  

--On Monday, April 6, 2020 08:07 -0700 Joseph Touch
<[email-masked]> wrote:

>> Why do RFC's have Editors or Authors? Why not let the heatmap
>> of the GitHub repo of the spec stand in?
> 
> Because authorship is - or should be - determined by a policy
> that can be complex and cannot be so trivially automated.
> 
> Although USC is not a paragon of ethics by any sort, it did
> have a reasonable policy on this matter that helps illustrate
> why it's not merely a matter of who contributes text:
> https://research.usc.edu/files/2011/07/URC_on_Authorship_and_A
> ttribution_10.20111.pdf
> <https://research.usc.edu/files/2011/07/URC_on_Authorship_and_
> Attribution_10.20111.pdf>
> 
> And yes, although this matters more for bean-counting tenure
> committees and deans - who paradoxically use the kind of blind
> automation you suggest above - it's no less relevant here in
> the IETF. The Author Overload policy only exacerbates this
> effect.

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 Apr 2020 14:30:42 -0400

--On Monday, April 6, 2020 11:18 +1200 Brian E Carpenter
<[email-masked]> wrote:

>>> The community of interest is NOT "those who read RFCs" and
>>> trying to do surveys of them a bad idea. The community of
>>> interest is NOT "anyone who cares enough to sign up here"
>>> although that might be convenient.
>>> 
>>> RFCs and the RFC series and streams have a role to play in
>>> assuring the robustness of the Internet. Reliability
>>> (especially in an always-update-software world) means
>>> avoiding vendor-lock-in as a single point of failure. The
>>> RFCs have a requirement to be somehow useful to the
>>> community involved in the process of specifying, producing,
>>> debugging, operating, documenting, etc multiple independent
>>> interoperable implementations.
> 

Agreed.
The last group you mentioned --which I'd expand to include those
writing contracts, SLAs and other specifications associated with
software acquisition and maintenance, and sometimes other people
associated with hiring, procurement, and statements of work as
well as occasional journalists -- may be worthy of special note
for several reasons:

(1) They often read RFCs using a medium that, from reading this
and related discussions, many of us consider archaic [1].  Many
of them even mark up those RFCs to make special notes or for
incorporation in specification documents using equally archaic,
pre-XML, techniques and procedures [2]. 

(2) In practice, their actions are often key to which products
are purchased, whether those products conform to (or are held
to) our standards or not, and so on.

(3) While the relationships may be quite indirect, their actions
often determine whether many IETF participants remain employed
and how they are compensated [3].

(4) The odds of getting either a significant number or a
representative sample of them to read and participate on an IETF
mailing list and/or a meeting (f2f or virtual) are just about
zero.  

However, for reasons that should be clear from the above (if
they weren't already), we ignore them at our peril.   If we
intend to support them, we need documents that are available in
forms that do not require additional processing (reformatting,
changes in layout, etc.) to work with their preferred medium
_and_ which are written clearly and in good English, preferably
good enough English that it is reasonable to expect translators
who are not expert in the subject matter (whether human or
machine) to be able to render them into other languages without
significant distortion of the information that is present.

Hypothesis #1: If we accept the assertion that textual forms are
insufficient to adequately represent the material we expect in
new-generation RFCs, the PDF has better work.  Really work.
And, if we produce versions that do not come up to those
standards with the expectation of reissuing them in better form
later, they should be clearly identified as "temporary",
"interim", "preliminary", "preprint" or equivalent and we should
expect that standards will not really be adopted until final
versions are available (many or most of the people described
above are known to have a distaste for moving targets).

Hypothesis #2: Producing output documents of that quality,
especially given the observable writing skills (in technical,
American, English) of many IETF participants can require rather
significant effort to rewrite paragraphs, reorganize material,
goes far beyond what is usually understood as "copy editing".
There are also obvious tradeoffs between quality and time and
cost in the editing process.  Decisions about those tradeoffs in
particular situations -- decisions that might include returning
a document to a Stream and telling them they have to make it
better before editing is feasible -- should be made by a skilled
professional, not a bureaucrat working from a single criterion,
if we want the Series to survive [4].

Hypothesis #3: An RSE, or RSE candidate, who does not thoroughly
understand the above is probably unsuited for the position.
Consequently, we need to capture those issues in a way that make
them a part of whatever job descriptions are developed.

thanks,
   john

[1] I think it is called, or used to be called, "paper",
typically paper organized into "pages" that readers expect to be
carefully laid out and "paginated".

[2] Examples of such ancient technology are known as "pencils"
and "pens", often in a multitude of colors.  Occasionally "copy
and paste" techniques are used that involve "scissors" and
"tape" or "glue".

[3] In discussions of economics, the outcome of those
relationships is sometimes known as "the bottom line".

[4] And, because some of the documents in the Series are the
IETF's main product as far as much of the public and those
audiences are concerned, perhaps even whether the IETF survives.

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 Apr 2020 14:56:43 -0400

--On Sunday, April 5, 2020 14:52 +0200 Eliot Lear
<lear=[email-masked]> wrote:

> Good questions, and I like Stephen's answer, but let me ask
> the question this way:
> 
> Do we want to ask the IAB to send liaisons to various places
> who we know use our output?  If we are discussing the form and
> future of the series itself, then I would think we'd want a
> broad approach.  If we are talking about the internal
> management and oversight of the role, and putting aside the
> form and future of the series, then I don't see the benefit.
> These are not binary. There's some crossover.

Eliot,

Drawing heavily from the note I sent in this thread a few
minutes ago (but not repeating it), I think what you describe as
a broad approach is needed.  But liaisons to the sorts of people
and groups I was describing in that note: I think pretty
hopeless even if we had enough people in the IETF to fill those
roles.

  best,
    john