Skip to main content

2018-08-23-rsoc-minutes
slides-interim-2022-rfcedprog-08-sessa-2018-08-23-rsoc-minutes-00

Meeting Slides RFC Series Oversight Committee (RSOC) (rfcedprog) IAB ASG
Date and time 2022-01-01 16:00
Title 2018-08-23-rsoc-minutes
State Active
Other versions plain text
Last updated 2022-06-10

slides-interim-2022-rfcedprog-08-sessa-2018-08-23-rsoc-minutes-00
RFC SERIES OVERSIGHT COMMITTEE (RSOC)
August 23, 2018 RSOC Meeting

Reported by: Cindy Morgan, IETF Secretariat

ATTENDEES
---------------------------------
 Sarah Banks (Chair) 
 Nevil Brownlee
 Heather Flanagan (RSE, non-voting)
 Tony Hansen 
 Bob Hinden
 Cindy Morgan (Scribe, non-voting)
 Adam Roach
 Robert Sparks (Lead) 
 Martin Thomson
 Portia Wenze-Danley 

REGRETS
---------------------------------
 Joel Halpern

MINUTES
---------------------------------

0. Review of minutes

  The minutes of the 19 July 2018 meeting were approved.

0a. Agenda bash

  The following new items were added to the agenda:

    - RFCs at ISI
    - rfc6635bis
    - Publishing copies of RFCs that incorporate errata

1. Format work update

  Heather Flanagan reported that that the svgcheck tool is waiting for 
  an update to the document with one last round of modifications. 
  Rfclint is complete and will just be responding to bug reports and 
  then the round of edits needed from the update of the RFC. Xmldiff 
  still needs the source windows to be complete so that all source files 
  are listed.  

  Robert Sparks asked if the v3 text formatter has been tested yet. 
  Heather Flanagan replied that it has, and that Alice Russo has sent 
  some bug reports to Henrik Levkowetz.

  Tony Hansen noted that he has had some conversations with Henrik 
  Levkowetz about making the tools available on the website. 

  Heather Flanagan replied that they are not looking for community 
  testers yet, as they would like to make sure that the tools work well 
  enough for the RPC before opening them up for community testing.

  Tony Hansen suggested that they could be put on a hidden page or the 
  experimental page. 

  Robert Sparks noted that anyone who downloads the most recent version 
  of XML2RFC will have the tools available, so he does not think there 
  is an issue with having them linked from the experimental page.

2. IAB and RSOC changes

  Robert Sparks reported that the IAB ran out of time to talk about the 
  RSOC appointments at their most recent meeting, but that he thinks 
  there is a high chance the IAB will finish this up in the next couple 
  of weeks.

3. Other in-progress items
3.1. Crossref and DOIs

  Heather Flanagan reported that the invoices from Crossref for 
  assigning DOIs were going to Ray Pelletier's old email address instead 
  of the generic iad@ietf.org address, so payment was past due and 
  Crossref sent a shut-off notice. Portia Wenze-Danley has all of the 
  old invoices and has updated the billing address, so DOIs should start 
  being assigned again shortly. The RFC Editor has not held up 
  publication of RFCs while this issue is being sorted out.

3.2. RFC Editor priorities

  Heather Flanagan reported that she is working on the list of RFC 
  Editor priorities and is reviewing that with the RPC. She expects that 
  this will be the main topic at the next RSOC meeting.

3.3. IPJ article

  Heather Flanagan reported that she is working on an article for the IP 
  Journal about the RFC Series celebrating 50 years of RFCs.

3.4. Streams and statuses

  Heather Flanagan reported that she has started working with Dan York 
  and Greg Wood on outreach regarding streams and statuses.

4. RPC update
4.1. GitHub experiment

  Heather Flanagan reported that she sent email to the IESG with the RFC 
  Editor's experience using GitHub during AUTH48. She noted that while 
  she can see why authors might like using it, it is not a particularly 
  efficient tool for copy editing. They still need to determine how to 
  revise the experiment before proceeding with the JSEP draft. updated 
  statistics regarding AUTH48 times during this experiment are on the 
  wiki at <https://www.rfc-editor.org/rse/wiki/doku.php?
  id=github_auth48_experiment>.

  Heather noted that if the RFC Editor does proceed with using GitHub as 
  a collaborative editing tool, that will further specialize the skill 
  set needed by editors, which will mean a longer ramp-up time when new 
  editors come on board.

  Nevil Brownlee asked how the RPC feels about Eric Rescorla's 
  suggestions for changing the experiment.

  Heather Flanagan replied that some of them would be easy to implement, 
  but others, such as using Markdown or a different editing tool would 
  only add extra complications. 

  Bob Hinden said that it sounds like the experiment was not successful 
  from the production center side, and that he does not think they 
  should be forced to use GitHub.

  Robert Sparks suggested that it might be worth exploring what the 
  impact on the RPC work flow would be if the editors' changes were 
  separated out between text changes and whitespace changes.

  Heather Flanagan replied that that would be difficult because that is 
  not how copy editing works; she talked about this with Alice Russo and 
  Lynne Bartholomew from the RPC and they could not come up with a way 
  to make that work. Heather suggested that Robert chat with them to see 
  if he can bring in a different perspective that would make that work.

  Tony Hansen suggested that there is a front-end tool into GitHub that 
  might make it easier for the RPC to use, but he is not familiar enough 
  with that tool or with GitHub to say whether that would be useful.

  Heather Flanagan said that the RPC is also not familiar with that 
  tool, and that she is hesitant to add another tool to the tool chain 
  without knowing how it would affect the editors' work flow.

  Adam Roach said that if using GitHub becomes standard operating 
  procedure, he suspects that some sort of tool on top of the existing 
  GitHub UI will be required in order to make it work.

  Heather Flanagan replied that in such case, the would need to be a 
  conversation about it with someone who is familiar with the GitHub 
  universe and someone who is familiar with the copy editing universe. 
  Heather said that she may try to find someone to have such a 
  conversation with Alice Russo at the next IETF meeting.

4.2. Format tool testing

  Heather Flanagan reported that format tool testing is in process. The 
  next big push for testing will happen once Henrik Levkowetz returns 
  from vacation.

  Tony Hansen asked where the ancillary tools can be found.

  Robert Sparks replied that right now the RPC is still testing them, so 
  they have not been announced to the community yet.

5. RFCs at ISI

  Heather Flanagan reported that the hard copies of early RFCs that are 
  being stored at ISI have been moved to a physically better location, 
  and that Bob Hinden asked if the question of getting the Computer 
  History Museum to take those RFCs from ISI should be revisited.

  Heather Flanagan noted that when she has tried to broker the 
  conversation in the past, she has not been able to make much progress 
  because ISI does not want to give the RFCs up.

  Nevil Brownlee asked if ISI would make the RFCs available to anyone 
  who would like to see them, like the Computer History Museum would.

  Tony Hansen asked if ISI would be amenable to having the RFCs scanned.

  Bob Hinden asked if anyone who isn't on the RSOC even knows that the 
  physical copies of early RFCs are being held at ISI.

  Heather Flanagan said that she would ask for answers to all of those 
  questions.

6. draft-ietf-iasa2-rfc6635bis

  Bob Hinden reported that he has a few more things to fix in draft-
  ietf-iasa2-rfc6635bis, "RFC Editor Model (Version 2)". The goal of 
  this update is to bring the document up to date with IASA 2.0 rather 
  that to make other changes.

  Nevil Brownlee pointed out that a similar update should probably be 
  made to RFC 6548, "Independent Submission Editor Model."

7. Publishing copies of RFCs that incorporate errata

  Adam Roach reported that the IESG has begun discussing ways to make 
  errata that has been approved more visible to implementers. He said 
  that while the IESG is still early in these conversations, the 
  direction seems to be leaning less towards publishing new documents 
  and more towards making tools changes that would allow for the errata 
  to be displayed inline.

  Robert Sparks said that displaying errata inline might be difficult 
  because a large portion of errata reports are fairly general and do 
  not include specific line changes. He suggested pulling up the 50 most 
  recent errata and trying to see from those what that sort of 
  automation would look like. He also noted that trying to force that 
  errata reports be submitted in a format that could result in inline 
  changes to the text might make it more difficult for people to call 
  out problems, so the problems will end up not being reported.

  Martin Thomson suggested that changing the errata report into 
  something that could result in inline text changes could be part of 
  the verification step rather than part of the reporting step.

  Tony Hansen suggested that errata could be appended one per page to 
  the end of a document.

  Adam Roach said that it sounds like there might be two different 
  formats for this, where some errata are displayed inline and others 
  are called out in the header of the document.

  Sarah Banks asked if displaying the errata inline would result in a 
  versioning problem when responding to subpoenas.

  Heather Flanagan replied that she does not think that would make a 
  difference; the original text is still there, and errata are currently 
  available publicly anyway.

  Bob Hinden observed that there seems to be a version of this today 
  already with the HTML RFCs on tools.ietf.org, and asked why that isn't 
  sufficient.

  Adam Roach replied that it is not very visible as it is, and it would 
  be better to have the errata appear at the point of the document that 
  is affected.

  Heather Flanagan added that one of the things they learned during the 
  RFC++ BOF is that people don't always pay attention to the headers of 
  documents.