Re: Community Input Sought on SOWs for RFC Production Center and RFC Publisher
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 f
RFC production center XML format usage, was: [IAOC] xml2rfc and legal services RFPs
>> Can the RFC Production Center remind us about what the actual numbers >> are, and also whether they ever generate an XML version if the authors >> didn't supply one? Julian's numbers are good approximations; 50-60% of docs have XML source files. The Production Center does not create XML files. We process XML files when XML source files are provided to us. Thanks, Sandy for the RFC Production Center > From: Julian Reschke > Date: February 23, 2011 5:09:54 AM EST > To: Russ Housley > Cc: dcroc...@bbiw.net, IAOC , IETF > Subject: RFC production center XML format usage, was: [IAOC] xml2rfc and > legal services RFPs > > On 23.02.2011 10:46, Julian Reschke wrote: >> On 22.02.2011 17:18, Russ Housley wrote: >>> > There are many tools used by I-D > authors, including nroff/troff/groff, NroffEdit, MS Word templates, > LaTex, > and a plethora of editors. The IETF cannot take on every tool that > seems > popular. Isn't the statistic of xml2rfc use somewhere around 50-60%? >>> >>> Roughly half. Again, that is why there is a value to the RFC >>> Production Center. >>> ... >> >> Can the RFC Production Center remind us about what the actual numbers >> are, and also whether they ever generate an XML version if the authors >> didn't supply one? >> ... > > I just realized that I have an archive of XML versions of RFCs in AUTH48 > state; so I *can* report the percentage of XML versions since ~RFC5000. > > Note that these may be inaccurate (for instance, not all RFC numbers get > assigned, right?); it just observes how much XML files ended up in AUTH48. > > Here are the numbers: > > RFC5000 - RFC5099: 41 > RFC5100 - RFC5199: 44 > RFC5200 - RFC5299: 47 > RFC5300 - RFC5399: 48 > RFC5400 - RFC5499: 64 > RFC5500 - RFC5599: 59 > RFC5600 - RFC5699: 58 > RFC5700 - RFC5799: 64 > RFC5800 - RFC5899: 63 > RFC5900 - RFC5999: 68 > RFC6000 - RFC6099: 69 > > Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: author's address (was: Re: Fwd: [OPS-DIR] OPS-DIR Reviewofdraft-yevstifeyev-tn3270-uri-12)
Greetings,
Sorry I'm late to the discussion, but I wanted to point out our actual policy
regarding the Author's Address:
From "RFC Document Style" (http://www.rfc-editor.org/rfc-style-guide/rfc-style)
4.9. "Author's Address" Section
This required section gives contact information for the author(s)
listed in the first-page header, and perhaps those listed in a
Contributors section.
Contact information must include at least one, and ideally would
include all, of a postal address, a telephone number and/or FAX
number, and a long-lived email address. The purpose of this section
is to (1) unambiguously define author/contributor identity (e.g., the
John Smith who works for FooBar Systems) and to (2) provide contact
information for future readers who have questions or comments. Note
that some professional societies offer long-lived email addresses for
their members.
Typically, we'll request an email address (at minimum) because we (RFC
Production Center) need to be able to contact the authors via email and get
author approval for the document.
Please let me know if you have any questions or if this causes any concern.
Thanks!
Sandy (for the RFC Production Center)
On Jan 14, 2011, at 7:06 AM, Marshall Eubanks wrote:
>
> On Jan 14, 2011, at 7:45 AM, Phillip Hallam-Baker wrote:
>
>> I believe that my personal security trumps any and all considerations that
>> might be raised here.
>>
>> I do not give my home address out and do not intend to change. If the RFC
>> editor were to insist that the fields are filled they are going to get a
>> fake address.
>>
>>
>
> They should not insist on anything of the sort.
>
>> Corporate addresses are even less useful. Very few people in the IETF have
>> the same employer for more than five years. And even those who have the same
>> employer are unlikely to have the same office building very long.
>>
>>
>> On Fri, Jan 14, 2011 at 4:11 AM, t.petch wrote:
>> - Original Message -
>> From: "Doug Ewell"
>> To: "The IETF"
>> Sent: Friday, January 14, 2011 6:56 AM
>> Subject: Re: author's address (was: Re: Fwd: [OPS-DIR] OPS-DIR
>> Reviewofdraft-yevstifeyev-tn3270-uri-12)
>>
>>
>>> Peter Saint-Andre wrote:
>>>
For what it's worth, Section 10 of the informational RFC 2223
("Instructions to RFC Authors") states:
Each RFC must have at the very end a section giving the author's
address, including the name and postal address, the telephone number,
(optional: a FAX number) and the Internet email address.
>>>
>>> The Internet is not the type of chummy small-town environment where we
>>> can trust just anybody with our home address and phone number, or our
>>> bank account and credit card numbers, and where we can leave our front
>>> doors unlocked at night.
>>
>> As Joel pointed out, the Last Call issue is the contact details for change
>> control
>> in the registration of a widely used URI with IANA, details which consist
>> solely of a gmail address. Is that enough to grant change control of this
>> URI (in which a number of people from a number of organisations have
>> expressed an ongoing interest)?
>>
>
> What, exactly, is the issue here ? How IANA authenticates someone with change
> control over some resource ?
> That, clearly, is a lot bigger than just this RFC. I would assume (and feel
> sure) that IANA is not just blindly going by
> email address, but by their judgement. I am also not sure what having an
> address will do to help with this. I doubt IANA
> will be sending inspectors to people's houses asking to see ID.
>
> If there seems to be of particular risk of such attacks for this URI, I would
> suggest adding
> text in the security section (or the IANA considerations).
>
> If impersonation attacks seem like a real threat in general, then someone who
> feels that way
> should write a draft specifying how IANA should authenticate people.
>
> Regards
> Marshall
>
>> RFC4395 appears to be silent.
>>
>> Tom Petch
>>
>>> I worked on two I-Ds in a WG where participant A once responded to
>>> participant B's support of an RFC 3683 P-R action against A by
>>> contacting B's employer, gleaned from his e-mail address, demanding that
>>> the employer take professional action against B. In this type of
>>> hostile environment, I declined to state my employer's name or post to
>>> the WG list from my work address, much less divulge other personal
>>> information, and edited both RFC 4645 and 5646 as "Consultant."
>>>
>>> The argument that personal information is necessary to distinguish the
>>> author from other people with the same name probably carries some weight
>>> for authors named "John Smith" or "Bob Miller." There are few enough
>>> people named "Doug Ewell" in the world that the risk of ambiguity of
>>> authorship seems much more remote than the risk to personal security if
>>> too much personal information is provided. I suspect the same is true
>>> for
Re: Lets be careful with those XML submissions to the RFC Editor
Greetings All, The RFC Editor does retrieve ALL approved IDs and compare our edited text with the originally approved ID, as posted in the internet- drafts repository. Often times, authors send us the XML file, and let us know that they have updated the file to reflect the requested RFC Editor notes, that they have updated the authors addresses section, or that they did a bit of editorial clean-up because of some last call comments or because they received comments from x, y, & z. The RFC Editor does not usually have a problem accepting these types of changes. The authors submit their updated files, and we use this file as a starting point for our editorial process. We then create a diff file between the newly edited version (which includes author edits and RFC Editor edits) of the text file and the originally submitted ID. During AUTH48, we provide the .xml, .txt, and -diff.html files to the authors, ADs, and WG chairs. Each time an author requests changes during AUTH48, all of the files get updated and notifications are sent to the authors, ADs, and WG chairs. When we notice unusual changes in these files, we request that the ADs approve the changes before we publish the document. (Therefore, our bugging Jari for approval.) Ensuring that the resulting text of the submitted XML source match identically the approved ID does not seem correct. I thought that part of the reason for the RFC Editor to move toward the use of XML2RFC was because (among others, but those relevant here) 1) it would be easier and more efficient for authors, and 2) the authors would like to have the ability to alter the text during AUTH48 themselves, instead of sending changes in the RFC Editor requested format. As such, we provide our edited version of the .xml file to the authors during AUTH48, and ask them to edit the file themselves. However, it is at this stage that we often see changes that require AD approval, as opposed to upon XML submission. The case in particular that started this tread resulted from changes that occurred during AUTH48. Sandy On Nov 26, 2007, at 7:03 AM, John C Klensin wrote: --On Monday, 26 November, 2007 11:21 +0100 Eliot Lear <[EMAIL PROTECTED]> wrote: This argues that XML files be submitted as the authoritative source at the time of WGLC, Paul, if they are going to be submitted at all, and the I-D manager generates the text. I'm fine with that, by the way. Eliot, I'd urge a little caution on this. I can't speak for others, but I tend to extensively annotate my working source extensively with comments about the source of a change, obsolete or alternate proposed text, proposals under discussion and what I think about them, etc. I generally consider that material confidential, especially when it responds to comments received off-list. I typically remove material of that type before handing the XML over to the RFC Editor but taking it out of the working drafts prior to WGLC or even prior to IETF LC (when some of it might be needed to review discussions of an issues and how and why it was resolved) risks the loss of important information. It seems to me that, regardless of whatever else we do, the RFC Editor should generate a document from the XML and compare it to whatever the IESG approved before going forward. Even if we insert other steps, that is probably a necessary precaution. I believe it is also sufficient, which makes it especially attractive. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
