2021-11-15-rsoc-minutes
slides-interim-2022-rfcedprog-11-sessa-2021-11-15-rsoc-minutes-00

RFC SERIES OVERSIGHT COMMITTEE (RSOC)
November 15, 2021 RSOC Meeting

Reported by: Cindy Morgan, IETF Secretariat

ATTENDEES
---------------------------------
- Sarah Banks 
- Jay Daley (IETF LLC Board Liaison, non-voting)
- Tony Hansen 
- Cullen Jennings (IAB Lead)
- John Levine, (Temporary RFC Series Project Manager, non-voting)
- Cindy Morgan (Scribe, non-voting)
- Adam Roach
- David Schinazi 
- Peter Saint-Andre (RSOC Chair) 

GUEST
---------------------------------
- Sandy Ginoza (RFC Production Center)


RSOC DECISIONS: 2021
---------------------------------

  - 2021-10-18: RSOC agrees that once 7991bis is stable, a script will 
    be used to fix the XML on documents that do not conform to RFC 7991, 
    and the documents will be re-rendered. After the documents are re-
    rendered, they will be checked to confirm that the text did not 
    change.

  - 2020 Decisions: 
<https://www.iab.org/wp-content/IAB-uploads/2021/01/rsoc-decisions-2020.txt>

  - 2019 Decisions: 
<https://www.iab.org/wp-content/IAB-uploads/2020/01/rsoc-decisions-2019.txt>


ACTION ITEM REVIEW
---------------------------------

In Progress:

  - 2021-10-18: John Levine to update draft-iab-rfc7991bis with help 
    from Peter Saint-Andre.
   * Deadline 2021-12

Updated:

  - 2021-11-16: Jay Daley to complete a website (authors.ietf.org) with 
    information on how to write an I-D and the tools available to 
    support this (Recommendation 8).
   * Deadline 2021-12


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

1. Administrivia

  The minutes of the 2021-10-18 RSOC meeting were approved.


2. v3 Issues and Tools

  John Levine reported that he is working on updates to draft-iab-
  rfc7991bis. He said that he understands the changes that need to be 
  made, but since there will be a lot of copying and pasting from the 
  XML documentation, it will be a bit labor intensive. Peter Saint-Andre 
  volunteered to help with that.  

  The GitHub repository for the document is:
  https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis.


3. Recommendations Following From the I-D Authors Survey

 * Recommendation 8:  An end-to-end analysis is carried out to ensure 
   that v3 XML can be used effectively and seamlessly at all stages of 
   the authoring process.

  Jay Daley reported that the uthors.ietf.org site is almost complete, 
  with the goal of having it finished by the end of the year. The site 
  provides authors with documentation about how to choose their format 
  and tools. The tools catalog catalog classifies which tools support 
  v3. Jay said that he hopes to put this out to the community for review 
  in the next week or so.

  The section on drafting in XML has a full vocabulary reference that 
  shows each of the elements, how the attributes work, and a copy of the 
  schema. All of the content is in GitHub so that people can make pull 
  requests against it to propose changes.

  Jay Daley noted that the site does not include the "Guidelines to 
  Authors of Internet-Drafts," <https://www.ietf.org/standards/ids/
  guidelines/>, which is owned by the IESG. The IESG would like the 
  Guidelines to reman on the main ietf.org site. Jay said that he would 
  copy content from the Guidelines over to authors.ietf.org as 
  appropriate.

  Peter Saint-Andre said that once the authors.ietf.org site is live, 
  recommendation 8 will have been addressed.

  * Updated Action Item: Jay Daley to complete a website 
    (authors.ietf.org) with information on how to write an I-D and the 
    tools available to support this. (Was: John Levine and Peter Saint-
    Andre to discuss the prioritization and time commitment needed to 
    put together an end-to-end analysis to ensure that v3 XML can be 
    used effectively and seamlessly at all stages of the authoring 
    process (Recommendation 8), and report back to the RSOC.

 -----------------------------------------------------------------------
 * Recommendation 5:  The process by which authors review RPC changes 
   should be examined with a view towards understanding what tooling is 
   required if this process is to use XML and not plain text as the 
   common format.

  Jay Daley said that he suggested that the RPC look into using the 
  Oxygen XML editor, but this would require each editor to have their 
  own copy of Oxygen XML, which would be a reasonable investment. The 
  editors need to be able to tell authors about the changes that they 
  have made to the text, and ask them to refer back to the XML to see if 
  that made any changes to how they expect the document to look. 
  Ideally, there would be a single tool where people can see what has 
  changed and all of the outputs, rather than having to put all of those 
  pieces together separately.

  Sandy Ginoza noted that the RPC currently sends any questions to the 
  authors in an email and embedded into the XML files themselves, so if 
  authors look at the diffs, they will see the questions and changes 
  inline. She noted that the RPC is using RFCdiff, which is 
  significantly different from XMLdiff, and she is not sure whether 
  RFCdiff is missing features that the authors used.

  Jay Daley said that the XMLdiff tool is unlikely to be completed based 
  on the original design, and if there is a concrete need for it, they 
  will need to make sure Robert Sparks and the Tools Team are aware.

 -----------------------------------------------------------------------
 * Recommendation 9:  A significant minority want to use Markdown or 
   similar and a strategic decision is needed on whether or not this 
   should be "officially" supported either in some stages or in the full 
   end-to-end authoring process. (see also Q20)

  Jay Daley asked whether the RSOC should consider Recommendation 9 now, 
  or if this is something that should be taken up by the RFC Series 
  Working Group (RSWG) once the RFC Editor Model (Version 3) is 
  complete. 

  Cullen Jennings asked whether this recommendation is about 
  commissioning the creation of a tool, or allowing Markdown to be the 
  archival format. Jay Daley replied that he thinks it is about having a 
  single Markdown syntax so that we can have an ecosystem of tools 
  around it that can translate to XML all the way through the AUTH48 
  process.

  Cullen Jennings observed that this would require a lot of extensions 
  to Markdown, many of which would be as esoteric as the extensions to 
  XML.

  David Schinazi said that the Markdown does not need to support every 
  single feature in XML; we just need something so that the RPC can 
  convert from Markdown to XML with one click. 

  Sandy Ginoza said that the RPC discussed experimenting with editing in 
  Markdown and doing the conversion to XML at the very end, but noted 
  that if that becomes widespread, it would be helpful to have one 
  uniform version of Markdown in order to lower the burden of training 
  new editors. 

  David Schinazi noted that the tools can tell which version of Markdown 
  Is used, and asked whether the formats were fundamentally different 
  enough that there is a learning curve.

  Jay Daley replied that the syntax is quite different. Cullen Jennings 
  added that kramdown and mmark handle references very differently.

  Peter Saint-Andre asked what they might want to learn by experimenting 
  with editing in Markdown.

  Sandy Ginoza replied that the RPC would want to find out:

    - Is it easier to edit in Markdown?
    - Does using Markdown make the AUTH48 process easier?
    - Does using Markdown make reviewing the final XML easier?

  Sandy Ginoza noted that the question of whether an experiment should 
  be under the purview of the RSWG still needs to be answered first. She 
  added that the current queue is pretty heavy, and adding an experiment 
  on top of that would slow things down more. 

  Peter Saint-Andre said that for the purpose of doing an experiment, 
  having a single Markdown language was not necessary. He also said that 
  experimenting with editing in Markdown would be under the RPC's remit 
  and does not need to wait for the RSWG. The main thing would be 
  choosing a document and finding a time to do the experiment when the 
  load in the queue is not too heavy already.

  David Schinazi noted that one of the major delays in the publication 
  process comes from waiting for authors to reply during AUTH48. He said 
  that he would find it easier to do AUTH48 review in GitHub, where 
  issues can be entered separately, rather than trying to respond to one 
  long email. 

  Sarah Banks reminded RSOC that not all Working Groups are comfortable 
  using GitHub.

  David Schinazi agreed that they don't want to disenfranchise anyone, 
  and that use of GitHub should be opt-in.

  Peter Saint-Andre said they should look at people's workflows and see 
  if there are ways to improve them. The RSOC will continue to think 
  about this topic and discuss it further at their next meeting.


4. RFC-Futures Update 

  Peter Saint-Andre reported that there continues to be much discussion 
  on draft-iab-rfcefdp-rfced-model coming out of the Program Last Call 
  on the document. He expects to have a new revision available later 
  this week.


5. Upcoming RSOC Meetings

  The RSOC agreed to change the date of their calls moving forward from 
  the third Monday of the month to the second Monday of the month in 
  order to avoid conflicts with several US holidays and IETF 113. The 
  next RSOC meeting will be at 1600 PST on Monday, 2021-12-13.