[rfc-i] Thoughts on the Independent Stream
eburger at standardstrack.com
Sat Oct 22 07:47:38 PDT 2011
A.k.a., tilting at windmills.
Consider this as comments to draft-iab-ise-model-01.
I would offer that the Independent Stream is obsolete. The need to create a venue to publish non-IETF standards publications is totally irrelevant now that we have this thing called the World Wide Web. There is a lot of confusion in the marketplace that an RFC is an IETF publication. MANY people who publish Independent Submissions do so with the explicit purpose of leveraging that confusion. I would offer the Independent Stream is destabilizing, evil, and something not to be supported.
The ONLY work product of the IETF is an RFC. Independent Submissions dilute the RFC brand. It is no solution for us to go out and say, "Yes, you think the work product of the IETF is an RFC, but it might not really be an IETF work product." That makes the RFC brand even more diminished than it already is with the presence of the Independent Stream.
I would like to point out that the average cost of RFC publication is $1,200 per RFC. However, the paid staff involvement in an Independent Stream RFC, per RFC 5620, is much higher than that of a Standards Track RFC. For the latter, the review is performed by volunteers. For Independent Stream documents, per RFC 5620 and as outlined in draft-iab-ise-model-01 in Section 2.2 bullet 2 (hence the relevance to this discussion), the ISE does the review, shepherding, and coordination. Instead of being done by volunteers, we pay the ISE. Therefore, I would expect the actual cost of publication of an Independent Stream RFC would be considerably greater than $1,200.
I am not a total naysayer. I understand the value of having an archival publication spot for non-IETF work that we want to let IETF participants and the Internet community at large to have access. Here are some proposals for how to achieve that goal.
If the purpose of taking independent documents is to truly gather requests for comment, then I would offer the existing I-D mechanism works perfectly. This is more especially so given that while I-D's expire in 6 months in theory, they actually are archived indefinitely.
If the purpose of taking independent documents is to document hard-to-get or possibly ephemeral, proprietary protocol specifications, we could use the IANA function or some other mechanism, such as piggy-backing on the RFC repository infrastructure, to stand up an archival web server. This will cost considerably less than $1,200 per document. So long as we do not call them RFCs, it means the only thing we need is to get copyright permission to put the document on-line. There would be no confusion with a given non-IETF document with an IETF RFC. Note that this eradicates the need for an Independent Submissions Editor, as there is nothing to edit. This eradicates Responsibilities (Section 2.2) 1, 2, 3, 4, and 6. Responsibility 5 just goes away, as there can be no errata to a non-IETF publication. If there is an error in the base document, the owner of that document can always submit a new version. Responsibility 7 does not require a human, and as such does not need to be done by the ISE.
So, if all Responsibilities go away, there is nothing for an ISE to do. If there is nothing for an ISE to do, there is no need to document what an ISE does. Since there is no need to document what an ISE does, there is no need to publish draft-iab-ise-model-01 as an RFC.
Short of archiving these non-IETF documents on IETF infrastructure, we could setup a DOI repository so people can find these proprietary documents.
If we are really tied to having an Independent Stream that produces RFCs, then I would offer that we follow the IEEE model. That model says that we will publish a document for free if it is less than, say, 4 pages. We will be happy to publish longer documents, but the person requesting publication would need to pay a per page fee. For comparison, the IEEE/ACM Transactions on Networking charges $220 per page over 10 pages. J-SAC charges $220 per page over 7 pages. If we are going to support confusion, there is no reason not to profit from it and at least generate some revenue to support the positive work that we do.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4897 bytes
Desc: not available
More information about the rfc-interest