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: - 2019 Decisions: 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," , 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.