Subject: [Rfced-future] some thoughts from the RPC

From: Sandy Ginoza <[email-masked]>
Date: Thu, 8 Oct 2020 12:37:05 -0700

Greetings all,

We’ve been invited by the IETF Executive Director and the Program Chairs to share some thoughts to help with the community discussion underway.  

The RPC read the proposals and has somewhat kept up with the discussion taking place on the list.  While being sensitive to the fact that we are a vendor, we have a few thoughts from the RPC perspective that we hope will be helpful as discussion about v3 of the RFC Editor model continues.  

Over the past 10 years, AMS has been part of implementing RFC Editor models v1 and v2.  During this time, the RPC has found it helpful to have someone engaged in the activities below (in no particular order), which allowed the RPC to focus on document production and process, and implementation of new developments.      
Note: we use “someone” because that is how the model was structured.  

a) evolve the series, considering community goals, series continuity, and best practices for publication and archiving (for example, the digital preservation considerations documented in RFC 8153)

b) when the strategic goals influence RPC priorities, weigh tradeoffs and explain the tradeoffs to the community; determine whether to implement changes based on tradeoffs and feedback received (for example, DOIs where the tradeoff was cost, both for the DOIs and contracted programming for automated uploads, and programming effort by the RPC to hold and display the data in various places)

c) monitor and engage in various community lists; outreach as needed to address concerns, and consider suggestions for further development

d) discern which suggestions are worth investigating further and implementing

e) update the Style Guide based on best common practice and input from the community and RPC

f) mediate/resolve any RFC-Editor-related conflict 

g) dive into RPC operations as needed, for example:
  - mediate author/RPC disputes (e.g., some authors object to the adopted Style Guide when applied to their documents or the Style Guide doesn’t address their issue; the RPC can usually, but not always, work through discrepancies with the authors)

  - provide input regarding best practices for archiving, display, etc. (fyi: there was a lot of discussion with the then-RSE about items like this in preparation for v3 transition)

h) make a decision or call consensus in a timely manner to keep things moving

Here are a few specific community suggestions we are aware of that may benefit from SME guidance: 

- revamp of the AUTH48 process
- addition of ePub as a publication format 
- a process by which bis documents can be turned around more quickly 
- revamp of the errata system 
- Style Guide updates
- v3 XML formatting guidance 

This information is provided simply to help the discussion along.  

Thank you,

Sandy Ginoza, Director
RFC Production Center
Association Management Solutions, LLC
5177 Brandin Court, Fremont, CA 94538
Phone: +1 (510) 492-4000

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 9 Oct 2020 09:07:51 -0700

> This information is provided simply to help the discussion along.

Sandy,

Thank you for bringing some concrete items to the table to potentially use
as examples for framing discussions.

-- 
Wes Hardaker
USC/ISI

---

From: John C Klensin <[email-masked]>
Date: Fri, 09 Oct 2020 15:54:39 -0400

Sandy,

I (at least) found this very helpful, not only for the
information and context but because you managed to present it
with none of the emotion that seems to overtake many of the rest
of us when discussing the issues and roles.

I hope everyone on the list reads your note and pays careful
attention.

thanks and best regards,
   john

--On Thursday, October 8, 2020 12:37 -0700 Sandy Ginoza
<[email-masked]> wrote:

> Greetings all,
> 
> We've been invited by the IETF Executive Director and the
> Program Chairs to share some thoughts to help with the
> community discussion underway.  
> 
> The RPC read the proposals and has somewhat kept up with the
> discussion taking place on the list.  While being sensitive to
> the fact that we are a vendor, we have a few thoughts from the
> RPC perspective that we hope will be helpful as discussion
> about v3 of the RFC Editor model continues.  
> 
> Over the past 10 years, AMS has been part of implementing RFC
> Editor models v1 and v2.  During this time, the RPC has found
> it helpful to have someone engaged in the activities below (in
> no particular order), which allowed the RPC to focus on
> document production and process, and implementation of new
> developments.       Note: we use "someone" because that is
> how the model was structured.  
> 
> a) evolve the series, considering community goals, series
> continuity, and best practices for publication and archiving
> (for example, the digital preservation considerations
> documented in RFC 8153)
> 
> b) when the strategic goals influence RPC priorities, weigh
> tradeoffs and explain the tradeoffs to the community;
> determine whether to implement changes based on tradeoffs and
> feedback received (for example, DOIs where the tradeoff was
> cost, both for the DOIs and contracted programming for
> automated uploads, and programming effort by the RPC to hold
> and display the data in various places)
> 
> c) monitor and engage in various community lists; outreach as
> needed to address concerns, and consider suggestions for
> further development
> 
>   - mediate author/RPC disputes (e.g., some authors object to
> the adopted Style Guide when applied to their documents or the
> Style Guide doesn't address their issue; the RPC can
> usually, but not always, work through discrepancies with the
> authors)
> 
>   - provide input regarding best practices for archiving,
> display, etc. (fyi: there was a lot of discussion with the
> then-RSE about items like this in preparation for v3
> transition)
> 
> - a process by which bis documents can be turned around more
> quickly  - revamp of the errata system 
> - Style Guide updates

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Oct 2020 16:38:01 +1300

Thanks, Sandy and Alice, very useful. May I ask a clarifying question? 

> f) mediate/resolve any RFC-Editor-related conflict 

Can you give some indication (obviously anonymized) about the sort of 
conflict that has arisen in the last few years, beyond "author/RPC
disputes"?

Regards
   Brian Carpenter

---

From: "John Levine" <[email-masked]>
Date: 11 Oct 2020 17:35:40 -0400

>conflict that has arisen in the last few years, beyond "author/RPC

In recent months the only dispute I can recall was with an author who
was outraged that the text version of his RFC doesn't have page
numbers, and was not impressed when I pointed out that was the outcome
of a very long process memorialized in RFC 7994.

Other than that it's been small judgement calls about whether it was
worth holding up publication to wait for an xml2rfc version that
improved the formatting or it was good enough as is.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 12 Oct 2020 10:11:44 +1100

> improved the formatting or it was good enough as is.

I assume that this is no longer a serious concern, as the output formats can be updated after the new version is released, right?

---

From: Christian Huitema <[email-masked]>
Date: Sun, 11 Oct 2020 16:17:23 -0700

> I assume that this is no longer a serious concern, as the output formats can be updated after the new version is released, right?

Did this group not decide a while back that we were not going to open
that particular kind of worms, the reference text for RFCs? That's
definitely an issue for who will be in charge next, but we don't need to
solve that *here*.

-- Christian Huitema

---

From: "John Levine" <[email-masked]>
Date: 11 Oct 2020 22:23:50 -0400

>> I assume that this is no longer a serious concern, as the output formats can be updated after the new version is released, right?

Sort of. The output files need to be good enough to be usable, but not
ideal perfectly typeset. With the current tool design, the PDFs will
never look fabulous because we don't have enough control over the
output formatting.

>that particular kind of worms, the reference text for RFCs?

The rendered formats are not canonical, but we seem to have a wide
variety of opinions about what "doesn't change" means.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Oct 2020 09:26:31 +0200

We should be careful not to get into the weeds.  The value of the RPC contribution from Sandy is to give us a feel for what we might call upon this person to do.  When thinking about this, one can consider the totality of that list or individual items.  The key question really is- who does that work, if anyone?

Eliot

> On 12 Oct 2020, at 04:23, John Levine <[email-masked]> wrote:
> 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

---

From: "John R Levine" <[email-masked]>
Date: 12 Oct 2020 10:38:02 -0400

> We should be careful not to get into the weeds.  The value of the RPC contribution from Sandy is to give us a feel for what we might call upon this person to do.  When thinking about this, one can…

Totally agree.

On the other hand, who would decide whether RFCs are always immutable 
might be a good straw man for the various governance proposals.  Not what 
the answer is, but how we would get to whatever the answer turned out to be.

R's,
John

---

From: Sandy Ginoza <[email-masked]>
Date: Tue, 13 Oct 2020 15:12:33 -0700

Hi Brian,

> On Oct 9, 2020, at 8:38 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> disputes”?

In addition to what John mentioned, a few other examples are
- navigating conflicting opinions regarding XML format
- which tools should be used to process documents
- overall level of edit provided 
- bigger disagreements with, or limitations of, the Style Guide

Thanks,
Sandy