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
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
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:
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:
Suggested:
4) Because the Publisher is responsible for the website, webmaster@xxxxxxxxxxxxxx is a Publisher address (and the address in mentioned in the Publisher SoW). We suggest that "webmaster@xxxxxxxxxxxxxx" be removed from the text below. Current:
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:
We suggest:
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
If "Forwarded Date" is changed to "Publication Date", then these items should also be updated: Current:
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:
Suggested:
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:
Suggested:
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:
Suggested:
(Note: SM also suggested making "Publisher's website" be "RFC Editor website") Current:
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:
Suggested:
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:
Suggested:
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:
Suggested:
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:
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:
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:
Suggested:
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:
Perhaps this should be updated as:
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:
|
