Re: Community Input Sought on SOWs for RFC Production Center and RFC Publisher

[Sandy Ginoza <[e-mail]>]

Greetings,

Since the publication of RFC 5620, the RFC Editor has been working to implement the RPC and Publisher split.  Based on our attempts to create two separable entities per RFC 5620 and later RFC 6635, our understanding of the motivations for splitting the RPC and Publisher into distinct functions, and our discussions with the RSE, the RSE has created a figure <http://www.rfc-editor.org/rse/wiki/lib/exe/detail.php?id=rfcpublisher&media=rfc-publisher-split-c.jpg> to describe where the split resides in practice.  We believe the figure accurately reflects the most practical split in terms of work allocation and portability.  

The split described in the figure eliminates the need for the Publisher to have staff with detailed RFC-specific knowledge by placing the majority of staff-related responsibilities with the RPC. Our understanding is that it is important for the SoWs to be aligned with the split described in the figure, so many of our comments below are an attempt to align these documents.  We provide our comments below for consideration. 

Thank you,
Sandy Ginoza 
(for the RPC and Publisher)


Notes: 
------

"Current" refers to text as provided in the Proposed SoWs: 
  http://iaoc.ietf.org/documents/RPC-Proposed-SoW-2013-final.pdf
  http://iaoc.ietf.org/documents/PUB-Proposed-SoW-2013-final_000.pdf

"Figure" refers to the figure available at 
  http://www.rfc-editor.org/rse/wiki/lib/exe/detail.php?id=rfcpublisher&media=rfc-publisher-split-c.jpg


RFC Production Center
---------------------

1) In the following, we suggest changing "reference IETF documents (RFCs and Internet Drafts)" to "referenced documents (RFCs and Internet Drafts)" because not all RFCs/I-Ds are IETF-stream documents.

Current:
1.2.  Validation of references

Ensure that references within specifications are available and that referenced IETF documents (RFCs and Internet Drafts) are latest versions available.  Also, match citations and references for consistency.  In the IETF standards stream, specific rules on the suitability and availability of references apply, as documented in RFC 2026 and successors, as interpreted by the IESG.  Editing of documents may be delayed waiting for normative references to become available.


2) In the following, we suggest that "ASN.1 (and particularly MIBs and MIB-related details)" be updated to reflect "MIBs".  Although MIB modules are written using a subset of ASN.1, the RPC does not check all ASN.1, we only check MIBs.  This change will reflect what is done in practice.  If the intent is to actually require the RPC to check all ASN.1, please let us know and we will discuss checking tools with the RSE and IAD.

Current:
1.3.  Validation of formal languages

The RPC should validate the syntax of sections of documents containing formal languages.  In particular ASN.1 (and particularly MIBs and MIB-related details), YANG, ABNF, and XML should be verified using one or more tools as approved by the RSE.      


3) Publication takes place in the "Electronic Signing & Announcements" box within the figure.  The following text does not seem to align with the figure:

Current:
2.     Documents forwarded to RFC Publisher

2.1.  The RPC will edit the documents from all streams consistent with the RFC Style Manual, the RFC Series, and the intent of the Authors.  Documents so edited will be placed in the ready-to-publish state and forwarded to the RFC Publisher.

In the figure, the publication-related actions occur on the RPC side because the RPC is responsible for posting RFCs in the public archive, sending out the RFC announcements, updating the various indexes, and digitally signing the RFCs.  This makes it possible for the RPC to respond to requests for legal verification of RFCs.  Therefore, we suggest the following update: 

2. Documents forwarded to RFC Publisher

2.1. The RPC will edit the documents from all streams consistent with the RFC Style Manual, the RFC Series, and the intent of the Authors.  Documents so edited will be published on the RFC Editor website. 

Alternately, Section 2.1 could be removed, as the documents will not be forwarded to the "Publisher" for publication and because how docs will be edited is discussed in Section 1.1.1.  


For consistency with the above update, we suggest that item 2.2 be updated as follows:

Current:
2.2. Additionally, the RPC will forward records of all interaction and edits relative to the document, including dialogue with the document authors and stream representatives, to the RFC Publisher for archiving.

Suggested:
2.2. The RPC will post all relevant documents, including the related RFC files, records of all interaction and edits relative to the document, dialogue with the document authors and stream representatives, on the RFC Publisher server for archiving.


4) Because the Publisher is responsible for the website, [e-mail] is a Publisher address (and the address in mentioned in the Publisher SoW). We suggest that "[e-mail]" be removed from the text below.

Current:
6.2.  Response to general questions directed to [e-mail] and [e-mail], coordinating as necessary with the RFC Publisher and RSE.


5) If item 3 (above) is accepted and Section 2.1 is updated or removed from the SoW, the Work Standards should be updated to refer to "publication" or "published" instead of "Forwarded Date" or "forwarded", for example:

Current:
A.2.1.1. A document is “received” by the RPC on the date of the receipt of a request to publish by the each of the respective streams (Receipt Date).

A.2.1.2. A document is “ready-to-publish” on the date it is forwarded to the RFC Publisher by the RPC (Forwarded Date).    

We suggest:
A.2.1.1. A document is “received” by the RPC on the date of the receipt of a request to publish by the each of the respective streams (Receipt Date).

A.2.1.2. A document is "published" on the date the RFC is made available on the RFC Editor website and the RFC announcement is sent (Publication Date).

Note that the contractual definition of the "Publication Date" is not new; it is currently defined in http://iaoc.ietf.org/documents/RFC-Publisher-Current-SOW-2012-5-24-11_000.pdf as 

The date of announcement is defined as the date of publication. 


If "Forwarded Date" is changed to "Publication Date", then these items should also be updated:

Current:
A.2.2.1. Processing times per document are from Receipt Date to Forwarded Date in total business days.

A.2.2.2. While the overall goal for document publication is 30 business days (6 weeks) from Receipt Date to Forwarded Date, the times measured in the defined Service Levels are times in RPC state.


6)  We suggest removing the first sentence of A.2.2.4 because it is redundant with earlier text and is not as clear as A.2.2.2, which can be summarized as: 

- Overall goal: time in all states (RFC-Editor-controlled states + 3rd party states) < 6 weeks
- Actually measured for SLA: time in RFC-Editor-controlled states

Note that we also recommend changing "RPC state" to "RFC-Editor-controlled states" throughout for clarity.  Alternately, we suggest that "RPC State" be defined as special term. 


Publisher
---------

7) In our understanding of the figure, the Publisher function provides access to the post-publication data, but the RPC would actually make any changes to post-publication data.  So, it seems inaccurate to include the Publisher is 'responsible for [...] post-publication data'.  Therefore, we suggest the following update:

Current:
The RFC Publisher function is described in RFC 6635 and is responsible for the storage and post-publication data for RFCs, access to the website, access to the errata reports, search tools and indexes, the archive of documents, and all backups and failover processes.

Suggested:
The RFC Publisher function is described in RFC 6635 and is responsible for the storage of and access to the website, errata reports, search tools and indexes, the archive of documents, and all backups and failover processes.


8) As mentioned in item 3 above, we believe that the action of publishing documents, and therefore the publication processes, are the responsibility of the RPC.  With that in mind, we suggest the following update to the Overview:

Current:
The Publisher will accept, store and publish documents from the RFC Production Center and
other material as determined by the RSE.  The RSE may authorize other entities to submit
documents directly for publication, but those documents are published on the authority of the
RSE.  Changes to the publication process and public-facing tools will be made under the advice
and approval of the RSE.

Suggested:
The Publisher will accept and store documents from the RFC Production Center and other material as determined by the RSE.  

We suggest that the remainder of the text be removed.  While the Publisher houses the tools used by the various RFC Editor components, it is the various components that have the staff to suggest and implement changes to the publication process and tools.

Also, it is not clear to us what is meant by "other entities to submit documents directly for publication".  Does this refer to web content or perhaps I-Ds that are to be published without being edited?  Both of these cases seem to fall into the RPC SoW, as the RPC is responsible for content on the website, and even if an I-D is to be published without changes, it would need to be updated to conform with current format and boilerplate standards.  Are there other cases in which this "directly for publication" may apply?


9) To make it clear that the RPC updates various data, and the Publisher simply makes it available on a server, we suggest changing these instances of "publish" and "post" to "make available" as follows:

Current:
RFCs are published on the Publisher’s website. This site includes one or more indexes with hyperlinked access to published documents as well as a convenient search engine.

Suggested:
RFCs are made available on the Publisher’s website. This site includes one or more indexes with hyperlinked access to published documents as well as a convenient search engine.

(Note: SM also suggested making "Publisher's website" be "RFC Editor website")


Current:
1.2.5.     post Web content as provided by the RSE, ISE, and/or the RFC Production Center,

We suggest deleting Section 1.2.5 from the Publisher SoW or updating it to read:
      1.2.5.     make available Web content as provided by the RSE, ISE, and/or the RFC Production Center,


Current: 
3.1.1.  Publish state information for each document in the publication process.

Suggested: 
3.1.1.  State information for each document in the publication process.


10) With the understanding that the RPC is responsible for creating and maintaining the web content (which presumably includes organizing the web content), and the Publisher for serving the content, we suggest this item be altered as follows. (Also: second sentence deleted because already covered in 1.2.6.)

Current:
1.2.7.     provide continual incremental improvements, including regularly redesigning web page trees to respond to common usage patterns.  However, stable identifiers must be maintained for the RFCs, archives, Errata, indices and other items.

Suggested:
1.2.7.  provide data about the website usage patterns so that the maintainers of the web content can organize it accordingly.


11) We believe the following item should be updated because an address should be provided to reach the Publisher (and this same address is used numerous times in Appendix 1 for items for which the Publisher is responsible) and because the RPC should not be a middleman in cases of server failure, etc. 

Current: 
1.4. Customer Support Services. Messages sent to certain conventional addresses as defined by the RSE, such as [e-mail], shall automatically be delivered to the RFC Production Center

Suggested: 
1.4. Customer Support Services. Messages sent to certain conventional addresses as defined by the RSE, such as [e-mail], shall be coordinated with the RPC as appropriate.


12) We question whether integration is really a publisher task.  The RPC has a programmer, so it seems the RPC would be responsible for the programming aspects and the Publisher would be responsible for ensuring the right access/security for integration. 

Current:
3.1.2.     Integrate Production Center state information with the IETF tools or such other tool sets as directed by the RSE to provide end-to-end status tracking of documents 

Perhaps Section 3.1.2 should be deleted, as Section 2.3.2 indicates that the Publisher should provide appropriate access for integration.


13) We suggest removing item 3.1.3, because it seems to be covered by providing state information, as described in Section 3.1.1.

Current:
3.1.3.     Provide external visibility regarding when a document is in an extended waiting period, the token-holder and circumstances of the wait.


14) While the Publisher may participate in discussions about the technical support systems required to address policy changes, we do not believe the Publisher needs to be involved in discussion regarding all publication policy changes.  Therefore, we suggest the following update:

Current:
6.1.  Participate in the discussions of the technical publication process with the RSE for policy changes.

Suggested:
6.1.  Participate in policy discussions about technical support of the publication process. 


15) It is not clear to us that the Publisher enforces RFC Series consistency, as the Publisher is responsible for making the files available and maintaining the archives.

Current: 
7.  Accountability

The Publisher is primarily responsible to the RSE as regards to RFC Series consistency.

Perhaps this should be updated as:
7.  Accountability

The Publisher is primarily responsible to the RSE regarding technical support and hosting of the RFC Series. 


15) The Work Standards are listed in "Exhibit B", but there is no "Exhibit A" - is some text missing, or should Exhibit B be Exhibit A?


On Aug 16, 2013, at 11:47 AM, Ray Pelletier wrote:

> All;
> 
> Are there any more comments on the SOWs?
> 
> This item will be on the IAOC agenda for its call on 22 August.
> 
> Ray
> 
> On Aug 12, 2013, at 5:54 PM, IETF Administrative Director wrote:
> 
>> The RFC Series Editor (RSE) is proposing changes to the Statements of Work (SOW) for the RFC 
>> Production Center (RPC) and the RFC Publisher.  The IAOC wants to receive community input prior to 
>> negotiating the proposed changes with the contractor.  Community input will be discussed with the RSE 
>> prior to negotiations and reviewed by the IAOC.
>> 
>> In forwarding the proposed Statements of Work the RSE said:  "The changes seek to make the SoWs 
>> more current [implementing RFC 6635] and specific, correcting the issues of "multiple masters" 
>> directing the RPC and Publisher, as well as preparing the way for a more significant revision to the SoWs
>> when the RFC Format changes are operationalized.  The SoWs have also been reviewed and supported 
>> by the RSOC [RFC Series Oversight Committee].  We consider the changes within the SoWs critical to the 
>> clear function of the RPC and Publisher, but suggest that the changes do not imply a significant change 
>> in responsibility for the RPC or Publisher."
>> 
>> The proposed SOWs, the current SOWs and a diff file for each can be found here under Community 
>> Review: <http://iaoc.ietf.org/rfps.html>
>> 
>> We appreciate the community's input and look forward to hearing from you.  
>> 
>> Thanks
>> 
>> Ray Pelletier
>> IAD
>