From pekkas at netcore.fi Wed Aug 6 23:06:51 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 7 Aug 2008 09:06:51 +0300 (EEST) Subject: [rfc-i] RFC 5287 on Time-Division Multiplexing (TDM) Pseudowires in MPLS NetworksControl Protocol Extensions for the Setup of In-Reply-To: <20080806232718.69CB914C016@bosco.isi.edu> References: <20080806232718.69CB914C016@bosco.isi.edu> Message-ID: Hmm, interesting -- the Title is wrapped. The title's second line is copied here first, then the first line. This is probably not intentional, but I wonder if this is a human or tools error. Metadata in indexes is also broken. On Wed, 6 Aug 2008, rfc-editor at rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 5287 > > Title: Time-Division Multiplexing (TDM) Pseudowires in > MPLS NetworksControl Protocol Extensions for the > Setup of > Author: A. Vainshtein, Y(J). Stein > Status: Standards Track > Date: August 2008 > Mailbox: Alexander.Vainshtein at ecitele.com, > yaakov_s at rad.com > Pages: 16 > Characters: 33070 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-pwe3-tdm-control-protocol-extensi-07.txt > > URL: http://www.rfc-editor.org/rfc/rfc5287.txt > > This document defines extension to the Pseudowire Emulation > Edge-to-Edge (PWE3) control protocol RFC 4447 and PWE3 IANA > allocations RFC 4446 required for the setup of Time-Division > Multiplexing (TDM) pseudowires in MPLS networks. [STANDARDS TRACK] > > This document is a product of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > USC/Information Sciences Institute > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce at ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From olaf at NLnetLabs.nl Thu Aug 7 03:20:32 2008 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Thu, 7 Aug 2008 12:20:32 +0200 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: <5.1.0.14.2.20080731074209.02df9b90@boreas.isi.edu> References: <5.1.0.14.2.20080731074209.02df9b90@boreas.isi.edu> Message-ID: Bob, First a few answers to your questions, then a few words on what I picked up in the hallways. On Jul 31, 2008, at 4:44 PM, Bob Braden wrote: > * Please give a concise summary of how this restructuring model > differs > from the current model. Note that the proposed model is so general > that it includes as > one case the current ISOC contract with ISI for RFC Editor services. This is the _first_ model of the RFC editor function. Under the current contract ISI performs almost all of the functions indicated in the diagram. The notable exception is that some early copy editing is done under direct contract under contract with ISOC, managed by the IAOC [1]. > * What will be the lengths of tenure of the independent submissions > supervisor and of the RFC Editor? Also, what length of time will > the contract with > the Production House cover? This is relevant to stability, > continuity, and staff > morale under the restructured organization. Currently the contracts that the IETF maintains with its vendors (ISI and AMS) are for 2 years with a possible extension of 1 year. My personal view on this is that the choice for contract terms is an IAOC matter. The trade-offs include stability, continuity and morale during the time that contracts are up for re-bid, the costs for the IETF (not only monetary) to have to change vendor, and allowing for a competitive proposition. > * Clearly indicate whether the positions described will be funded by > ISOC, or will get only travel and similar "administrative" expenses > reimbursed. Actually, this is one of the open questions in the model. There are two alternatives for the selection of the persons/institutions filling the role of Independent Stream Approver and the RFC Editor functions: Through a nomcom like process or trhough RFP-ing. Also the funding of those roles are subject to guidance from the community. Clearly, the selection and payment are tightly bound. > * The (new) RFC Editor position is implied to be a manager and have > responsibilities, yet this position has no authority. > Responsibility > without authority is a well-known "bog". I realize that there is a risk that my answer will start a debate about semantics. Within the IETF community there are a number of positions (ADs, WG- chairs, IAB membership, Nomcom membership) where by taking responsibility folk are being granted authority. And although folk in those positions have a small toolkit if it comes to the available carrots and sticks this all seems to work to some extend. It is up to the parties involved in the model, including the IAB and IAOC, to grant the authority to the RFC editor. I hear you pointing out that there are risks that that may fail. --- Some feedback I got in the hallway. Paraphrasing various folk, without giving attribution. Mainly because I forgot who said what and I may actually misquote them. 1. The Independent Stream Approver job title The Independent Stream Approver is an unattractive name for the function. It sounds like an accountant/auditing function not as the "Chief Editor" of a important and relevant publication stream. Personally I think that this is a fair point. Suggestions for another title that is more attractive are welcome. 2. Coupling of production house and the RFC Editor role. A few folks mentioned that it is probably not a good idea to separate the RFC Editor role from the Production house role. Here we have to make a distinction between the model and its implementation. The model currently separates the roles while it allows for an implementation that awards the responsibilities to separate persons/institutions. The model also allows an implementation that bundles those roles (and the others) and award them in a single contract. The last point that Bob made above argues to bundle the roles. However, the question is wether on the long term there are benefits for maintaining a distinction between the roles. It occurs that maintaining the rfc-editor and production house as seperate roles from a model that describes the production and its processes allows for some flexibility in the future. I hope that with this mail more comments and feedback are triggered. --Olaf (wearing no particular hats) [1] For the benefit of folk not familiar with this: an example of such contract can be found at http://iaoc.ietf.org/documents/CopyEdit_Contract.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 235 bytes Desc: This is a digitally signed message part Url : http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20080807/01bea1b6/PGP.bin From hgs at cs.columbia.edu Thu Aug 7 05:33:34 2008 From: hgs at cs.columbia.edu (Henning Schulzrinne) Date: Thu, 7 Aug 2008 08:33:34 -0400 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: References: <5.1.0.14.2.20080731074209.02df9b90@boreas.isi.edu> Message-ID: It is not clear whether the discussion is based on experience in the technical and scientific publishing world, or if the rough correspondence is an accident. I sit on the steering committee of the IEEE/ACM Transactions on Networking, and their model, which is very similar to most journals I know of, is as follows: - The steering committee selects an editor-in-chief, for a finite, non- renewable term. That position is a volunteer position. The EiC sets general policy (usually in discussions with the steering committee), gets involved in editorial disputes, nominates new associate editors and observes the work flow. In particular, the EiC is generally held responsible if the time-to-publish starts increasing. The position is assumed to be part-time for the person holding it. The EiC is not expected to read every paper that is published and does not generally make accept/reject decisions, but may get involved in process-level issues, such as perceived unfairness or incompetence by an associate editor. (Some compsci journals have long-term EiCs; IEEE and ACM seem to have term limits.) - The EiC is supported by an assistant, paid by the technical society, to manage the day-to-day affairs of the journal, such as hounding tardy associate editors or answering author questions. - Copy editing and production are handled by a separate entity, typically the society and its contractors, on a timescale that is measured in decades, i.e., independent of the term of the EiC. - Some magazines (say, IEEE Network Magazine) have special editors for major sections. There are obvious similarities to the proposal and, in some aspects, the RFC series has strong similarities to journal publishing. (It is no accident that RFCs got an ISSN, after all.) Thus, it may be useful to see if there are lessons and terminology that can be adopted. Henning On Aug 7, 2008, at 6:20 AM, Olaf Kolkman wrote: > > > Bob, > > First a few answers to your questions, then a few words on what I > picked up in the hallways. > > On Jul 31, 2008, at 4:44 PM, Bob Braden wrote: >> * Please give a concise summary of how this restructuring model >> differs >> from the current model. Note that the proposed model is so general >> that it includes as >> one case the current ISOC contract with ISI for RFC Editor services. > > > This is the _first_ model of the RFC editor function. Under the > current contract ISI performs almost all of the functions indicated > in the diagram. The notable exception is that some early copy > editing is done under direct contract under contract with ISOC, > managed by the IAOC [1]. > > > >> * What will be the lengths of tenure of the independent submissions >> supervisor and of the RFC Editor? Also, what length of time will >> the contract with >> the Production House cover? This is relevant to stability, >> continuity, and staff >> morale under the restructured organization. > > Currently the contracts that the IETF maintains with its vendors > (ISI and AMS) are for 2 years with a possible extension of 1 year. > > My personal view on this is that the choice for contract terms is an > IAOC matter. The trade-offs include stability, continuity and morale > during the time that contracts are up for re-bid, the costs for the > IETF (not only monetary) to have to change vendor, and allowing for > a competitive proposition. > > >> * Clearly indicate whether the positions described will be funded >> by ISOC, or will get only travel and similar "administrative" >> expenses reimbursed. > > > Actually, this is one of the open questions in the model. There are > two alternatives for the selection of the persons/institutions > filling the role of Independent Stream Approver and the RFC Editor > functions: Through a nomcom like process or trhough RFP-ing. Also > the funding of those roles are subject to guidance from the > community. Clearly, the selection and payment are tightly bound. > > >> * The (new) RFC Editor position is implied to be a manager and have >> responsibilities, yet this position has no authority. >> Responsibility >> without authority is a well-known "bog". > > > I realize that there is a risk that my answer will start a debate > about semantics. > > Within the IETF community there are a number of positions (ADs, WG- > chairs, IAB membership, Nomcom membership) where by taking > responsibility folk are being granted authority. And although folk > in those positions have a small toolkit if it comes to the available > carrots and sticks this all seems to work to some extend. > > It is up to the parties involved in the model, including the IAB and > IAOC, to grant the authority to the RFC editor. I hear you pointing > out that there are risks that that may fail. > > --- > > Some feedback I got in the hallway. Paraphrasing various folk, > without giving attribution. Mainly because I forgot who said what > and I may actually misquote them. > > 1. The Independent Stream Approver job title > > The Independent Stream Approver is an unattractive name for the > function. It sounds like an accountant/auditing function not as the > "Chief Editor" of a important and relevant publication stream. > > Personally I think that this is a fair point. Suggestions for > another title that is more attractive are welcome. > > > 2. Coupling of production house and the RFC Editor role. > > A few folks mentioned that it is probably not a good idea to > separate the RFC Editor role from the Production house role. > > Here we have to make a distinction between the model and its > implementation. The model currently separates the roles while it > allows for an implementation that awards the responsibilities to > separate persons/institutions. The model also allows an > implementation that bundles those roles (and the others) and award > them in a single contract. The last point that Bob made above argues > to bundle the roles. > > However, the question is wether on the long term there are benefits > for maintaining a distinction between the roles. It occurs that > maintaining the rfc-editor and production house as seperate roles > from a model that describes the production and its processes allows > for some flexibility in the future. > > > I hope that with this mail more comments and feedback are triggered. > > --Olaf (wearing no particular hats) > > > > > [1] For the benefit of folk not familiar with this: an example of > such contract can be found at http://iaoc.ietf.org/documents/CopyEdit_Contract.pdf > _______________________________________________ > rfc-interest mailing list > rfc-interest at rfc-editor.org > http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest From rfc-editor at rfc-editor.org Thu Aug 7 09:09:55 2008 From: rfc-editor at rfc-editor.org (RFC Editor) Date: Thu, 7 Aug 2008 09:09:55 -0700 Subject: [rfc-i] RFC 5287 on Time-Division Multiplexing (TDM) Pseudowires in MPLS NetworksControl Protocol Extensions for the Setup of In-Reply-To: References: <20080806232718.69CB914C016@bosco.isi.edu> Message-ID: <20080807160955.GA4316@isi.edu> Hi Pekka, Thanks for bringing this to our attention! Unfortunately, it was a manual error when inputting the title into our database. We have corrected the error, and the related metadata. Hopefully, we won't see this error again. Thanks! RFC Editor/sg On Thu, Aug 07, 2008 at 09:06:51AM +0300, Pekka Savola wrote: > Hmm, interesting -- the Title is wrapped. The title's second line is > copied here first, then the first line. This is probably not > intentional, but I wonder if this is a human or tools error. > Metadata in indexes is also broken. > > On Wed, 6 Aug 2008, rfc-editor at rfc-editor.org wrote: > >A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 5287 > > > > Title: Time-Division Multiplexing (TDM) Pseudowires in > > MPLS NetworksControl Protocol Extensions for the > > Setup of > > Author: A. Vainshtein, Y(J). Stein > > Status: Standards Track > > Date: August 2008 > > Mailbox: Alexander.Vainshtein at ecitele.com, > > yaakov_s at rad.com > > Pages: 16 > > Characters: 33070 > > Updates/Obsoletes/SeeAlso: None > > > > I-D Tag: draft-ietf-pwe3-tdm-control-protocol-extensi-07.txt > > > > URL: http://www.rfc-editor.org/rfc/rfc5287.txt > > > >This document defines extension to the Pseudowire Emulation > >Edge-to-Edge (PWE3) control protocol RFC 4447 and PWE3 IANA > >allocations RFC 4446 required for the setup of Time-Division > >Multiplexing (TDM) pseudowires in MPLS networks. [STANDARDS TRACK] > > > >This document is a product of the Pseudo Wire Emulation Edge to Edge > >Working Group of the IETF. > > > >This is now a Proposed Standard Protocol. > > > >STANDARDS TRACK: This document specifies an Internet standards track > >protocol for the Internet community,and requests discussion and suggestions > >for improvements. Please refer to the current edition of the Internet > >Official Protocol Standards (STD 1) for the standardization state and > >status of this protocol. Distribution of this memo is unlimited. > > > >This announcement is sent to the IETF-Announce and rfc-dist lists. > >To subscribe or unsubscribe, see > > http://www.ietf.org/mailman/listinfo/ietf-announce > > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > > >For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > >For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > > >Requests for special distribution should be addressed to either the > >author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless > >specifically noted otherwise on the RFC itself, all RFCs are for > >unlimited distribution. > > > > > >The RFC Editor Team > >USC/Information Sciences Institute > > > > > >_______________________________________________ > >IETF-Announce mailing list > >IETF-Announce at ietf.org > >https://www.ietf.org/mailman/listinfo/ietf-announce > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From braden at ISI.EDU Thu Aug 7 13:52:16 2008 From: braden at ISI.EDU (Bob Braden) Date: Thu, 7 Aug 2008 13:52:16 -0700 (PDT) Subject: [rfc-i] Some questions about the RFC Editor restructuring plan Message-ID: <200808072052.NAA21219@gra.isi.edu> *> *> - Copy editing and production are handled by a separate entity, *> typically the society and its contractors, Henning, Very interesting! How precisely do the copy editors interact with the associate editors? How often, and to what end? Thanks, Bob Braden From braden at ISI.EDU Thu Aug 7 14:24:54 2008 From: braden at ISI.EDU (Bob Braden) Date: Thu, 7 Aug 2008 14:24:54 -0700 (PDT) Subject: [rfc-i] Some questions about the RFC Editor restructuring plan Message-ID: <200808072124.OAA21249@gra.isi.edu> *> Henning, *> *> Very interesting! *> *> How precisely do the copy editors interact with the associate editors? *> How often, and to what end? *> Ooops. I meant, "How, precisely, do the ..." (blush) Bob Braden *> Thanks, *> *> Bob Braden From brian.e.carpenter at gmail.com Thu Aug 7 14:26:20 2008 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 08 Aug 2008 09:26:20 +1200 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: References: <5.1.0.14.2.20080731074209.02df9b90@boreas.isi.edu> Message-ID: <489B687C.4050603@gmail.com> On 2008-08-07 22:20, Olaf Kolkman wrote: ... > 1. The Independent Stream Approver job title > > The Independent Stream Approver is an unattractive name for the > function. It sounds like an accountant/auditing function not as the > "Chief Editor" of a important and relevant publication stream. > > Personally I think that this is a fair point. Suggestions for another > title that is more attractive are welcome. I was certainly one of the people who said this, so I'd better make a suggestion. Since we need "RFC Editor" for the overall function, how about "RFC Reviewing Editor [for the Independent Stream]" where the part in brackets is only used when clarification is needed. (Which makes me wonder whether the "RFC Editor" job title in the new proposal should be "RFC Managing Editor".) This relates to: On 2008-08-08 00:33, Henning Schulzrinne wrote: > It is not clear whether the discussion is based on experience in the > technical and scientific publishing world, or if the rough > correspondence is an accident. IMHO there is only a partial correspondence, because an independent peer review process is needed only for the Independent Stream. So I think there is a strong analogy between the "RFC Reviewing Editor" and an academic editor-in-chief, and between the RFC "Editorial Review Board" [RFC4846] and an academic editorial board, *but* the analogies only apply to the Independent Stream. Brian From hgs at cs.columbia.edu Thu Aug 7 14:30:06 2008 From: hgs at cs.columbia.edu (Henning Schulzrinne) Date: Thu, 7 Aug 2008 17:30:06 -0400 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: <200808072052.NAA21219@gra.isi.edu> References: <200808072052.NAA21219@gra.isi.edu> Message-ID: Bob, this is probably where the analogy with the RFC editing process breaks down. The job of the associate editor is done once the paper has been accepted. (Most papers go through at least two revision and review cycles, with shepherding by the associate editor, but that's more akin to the WG process.) From then on, the author(s) interact with the production part of the process. For each journal, that tends to be one person, so that there's a fair amount of consistency. Typically, they get a "proof" back from the production side and can then mark it up, kind of like AUTH48. Unlike during AUTH48, associate editors don't worry so much about authors "sneaking in" changes... Henning On Aug 7, 2008, at 4:52 PM, Bob Braden wrote: > > > *> > *> - Copy editing and production are handled by a separate entity, > *> typically the society and its contractors, > > Henning, > > Very interesting! > > How precisely do the copy editors interact with the associate editors? > How often, and to what end? > > Thanks, > > Bob Braden > From braden at ISI.EDU Thu Aug 7 14:29:51 2008 From: braden at ISI.EDU (Bob Braden) Date: Thu, 7 Aug 2008 14:29:51 -0700 (PDT) Subject: [rfc-i] Some questions about the RFC Editor restructuring plan Message-ID: <200808072129.OAA21270@gra.isi.edu> *> > Personally I think that this is a fair point. Suggestions for another *> > title that is more attractive are welcome. *> Independent Submission Editor? From gih at apnic.net Thu Aug 7 15:15:58 2008 From: gih at apnic.net (Geoff Huston) Date: Fri, 08 Aug 2008 08:15:58 +1000 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: <489B687C.4050603@gmail.com> References: <5.1.0.14.2.20080731074209.02df9b90@boreas.isi.edu> <489B687C.4050603@gmail.com> Message-ID: <489B741E.4010701@apnic.net> Brian E Carpenter wrote: > On 2008-08-07 22:20, Olaf Kolkman wrote: > ... >> 1. The Independent Stream Approver job title >> >> The Independent Stream Approver is an unattractive name for the >> function. It sounds like an accountant/auditing function not as the >> "Chief Editor" of a important and relevant publication stream. >> >> Personally I think that this is a fair point. Suggestions for another >> title that is more attractive are welcome. > > I was certainly one of the people who said this, so I'd better make > a suggestion. Since we need "RFC Editor" for the overall function, > how about "RFC Reviewing Editor [for the Independent Stream]" where > the part in brackets is only used when clarification is needed. Creating obfuscated titles is a wonderful, but ultimately pointless, game If the job is to review independent submissions then call the job "Independent Submission Reviewer" Or is that just too practical? Geoff From braden at ISI.EDU Thu Aug 7 15:25:31 2008 From: braden at ISI.EDU (Bob Braden) Date: Thu, 7 Aug 2008 15:25:31 -0700 (PDT) Subject: [rfc-i] Some questions about the RFC Editor restructuring plan Message-ID: <200808072225.PAA21280@gra.isi.edu> *> From then on, the author(s) interact with the production part of the *> process. For each journal, that tends to be one person, so that *> there's a fair amount of consistency. Typically, they get a "proof" *> back from the production side and can then mark it up, kind of like *> AUTH48. Unlike during AUTH48, associate editors don't worry so much *> about authors "sneaking in" changes... *> Do the markups go back to the authors to make corrections, or ...? AUTH48 happens generally after a good deal of editing for English grammar, consistency, etc. Maybe the articles that make it to the copy editors are more consistently well formed than the average Internet Draft? Bob *> Henning *> *> On Aug 7, 2008, at 4:52 PM, Bob Braden wrote: *> *> From brian.e.carpenter at gmail.com Thu Aug 7 15:37:27 2008 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 08 Aug 2008 10:37:27 +1200 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: <489B741E.4010701@apnic.net> References: <5.1.0.14.2.20080731074209.02df9b90@boreas.isi.edu> <489B687C.4050603@gmail.com> <489B741E.4010701@apnic.net> Message-ID: <489B7927.9090502@gmail.com> On 2008-08-08 10:15, Geoff Huston wrote: > Brian E Carpenter wrote: >> On 2008-08-07 22:20, Olaf Kolkman wrote: >> ... >>> 1. The Independent Stream Approver job title >>> >>> The Independent Stream Approver is an unattractive name for the >>> function. It sounds like an accountant/auditing function not as the >>> "Chief Editor" of a important and relevant publication stream. >>> >>> Personally I think that this is a fair point. Suggestions for another >>> title that is more attractive are welcome. >> >> I was certainly one of the people who said this, so I'd better make >> a suggestion. Since we need "RFC Editor" for the overall function, >> how about "RFC Reviewing Editor [for the Independent Stream]" where >> the part in brackets is only used when clarification is needed. > > > Creating obfuscated titles is a wonderful, but ultimately pointless, game > > If the job is to review independent submissions then call the job > "Independent Submission Reviewer" > > Or is that just too practical? I'll be frank. I think we'll be hoping to get an academic to do this pro bono, just as other journals like to have respected academics as editor-in-chief. So I think the job has to sound academically respectable, and the word "editor" does that. Would you go for "Independent Submission Editor"? Brian From paul.hoffman at vpnc.org Thu Aug 7 15:40:09 2008 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Thu, 7 Aug 2008 15:40:09 -0700 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: <200808072129.OAA21270@gra.isi.edu> References: <200808072129.OAA21270@gra.isi.edu> Message-ID: At 2:29 PM -0700 8/7/08, Bob Braden wrote: >Independent Submission Editor? That sounds good. --Paul Hoffman, Director --VPN Consortium From gih at apnic.net Thu Aug 7 16:33:26 2008 From: gih at apnic.net (Geoff Huston) Date: Fri, 08 Aug 2008 09:33:26 +1000 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: <489B7927.9090502@gmail.com> References: <5.1.0.14.2.20080731074209.02df9b90@boreas.isi.edu> <489B687C.4050603@gmail.com> <489B741E.4010701@apnic.net> <489B7927.9090502@gmail.com> Message-ID: <489B8646.1060506@apnic.net> Brian E Carpenter wrote: > On 2008-08-08 10:15, Geoff Huston wrote: >> Brian E Carpenter wrote: >>> On 2008-08-07 22:20, Olaf Kolkman wrote: >>> ... >>>> 1. The Independent Stream Approver job title >>>> >>>> The Independent Stream Approver is an unattractive name for the >>>> function. It sounds like an accountant/auditing function not as the >>>> "Chief Editor" of a important and relevant publication stream. >>>> >>>> Personally I think that this is a fair point. Suggestions for another >>>> title that is more attractive are welcome. >>> I was certainly one of the people who said this, so I'd better make >>> a suggestion. Since we need "RFC Editor" for the overall function, >>> how about "RFC Reviewing Editor [for the Independent Stream]" where >>> the part in brackets is only used when clarification is needed. >> >> Creating obfuscated titles is a wonderful, but ultimately pointless, game >> >> If the job is to review independent submissions then call the job >> "Independent Submission Reviewer" >> >> Or is that just too practical? > > I'll be frank. I think we'll be hoping to get an academic to do this > pro bono, just as other journals like to have respected academics as > editor-in-chief. So I think the job has to sound academically respectable, > and the word "editor" does that. Would you go for "Independent Submission > Editor"? Its acceptably warm for me, but then I'm not putting up my hand to do this for free :-) From hgs at cs.columbia.edu Thu Aug 7 16:42:26 2008 From: hgs at cs.columbia.edu (Henning Schulzrinne) Date: Thu, 7 Aug 2008 19:42:26 -0400 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: <200808072225.PAA21280@gra.isi.edu> References: <200808072225.PAA21280@gra.isi.edu> Message-ID: <90DDA4DE-DB41-4567-9865-2D631B0F7723@cs.columbia.edu> On Aug 7, 2008, at 6:25 PM, Bob Braden wrote: > > Do the markups go back to the authors to make corrections, or ...? > Yes, to verify that nothing got mangled in the typesetting/editing, given that many papers are rather specialized and technical. > AUTH48 happens generally after a good deal of editing for English > grammar, consistency, etc. Maybe the articles that make it to the > copy editors are more consistently well formed than the average > Internet Draft? This seems to depend strongly on the journal/magazine. The made-over Communication of the ACM (CACM) is apparently having an editor more or less rewrite submitted research articles for the broader target audience, while some of the more specialized journals, such as the Transactions on Networking, seem to apply a light editing touch, relying on earlier rounds of peer reviews to straighten out the English. Some authors are explicitly told to get external help if the text is in bad shape. > > > Bob > > *> Henning > *> > *> On Aug 7, 2008, at 4:52 PM, Bob Braden wrote: > *> > > *> From falk at bbn.com Fri Aug 8 07:03:37 2008 From: falk at bbn.com (Aaron Falk) Date: Fri, 8 Aug 2008 10:03:37 -0400 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: References: <5.1.0.14.2.20080731074209.02df9b90@boreas.isi.edu> Message-ID: On Aug 7, 2008, at 6:20 AM, Olaf Kolkman wrote: >> * The (new) RFC Editor position is implied to be a manager and have >> responsibilities, yet this position has no authority. >> Responsibility >> without authority is a well-known "bog". > > > I realize that there is a risk that my answer will start a debate > about semantics. > > Within the IETF community there are a number of positions (ADs, WG- > chairs, IAB membership, Nomcom membership) where by taking > responsibility folk are being granted authority. And although folk > in those positions have a small toolkit if it comes to the available > carrots and sticks this all seems to work to some extend. > > It is up to the parties involved in the model, including the IAB and > IAOC, to grant the authority to the RFC editor. I hear you pointing > out that there are risks that that may fail. Hmm, well, the ability for an RFC Editor to be responsible for series continuity, style management, and errata is going to be very different based on whether that person has financial control over the production process. Any changes will have an associated cost and consume resources (e.g., creating or modifying editorial standards, software, or process descriptions). If the RFC Editor doesn't control resources, they can only criticize and suggest, not **be responsible** for implementing improvements. This will create a three-way tension between the Production House (who needs to manage to cost and contractual agreements), the IAOC/IAD (who holds sets the contracts and who, btw, isn't shown on the diagram at [1]), and the RFC Editor (who has neither contract nor funding to push the Production House in a desired direction). If the RFC Editor has any authority at all, this seems like a potential mess of unclear management authority. If they don't and provide only an advisory role, I think their ability to **be responsible** for maintaining the quality of the series is going to be very limited. --aaron (also wearing no particular hats) [1] http://www.iab.org/documents/resources/RFC-Editor-Model.html From braden at ISI.EDU Fri Aug 8 11:15:13 2008 From: braden at ISI.EDU (Bob Braden) Date: Fri, 8 Aug 2008 11:15:13 -0700 (PDT) Subject: [rfc-i] Some questions about the RFC Editor restructuring plan Message-ID: <200808081815.LAA21499@gra.isi.edu> Henning, Several more questions arise from your explanation. *> *> - The steering committee selects an editor-in-chief, for a finite, non- *> renewable term. That position is a volunteer position. The EiC sets Who selects the steering committee? *> general policy (usually in discussions with the steering committee), *> gets involved in editorial disputes, nominates new associate editors *> and observes the work flow. In particular, the EiC is generally held *> responsible if the time-to-publish starts increasing. The position is What means does the EiC have at his/her disposal to reduce the time-to- publish? Hire more editorial people and/or authorize overtime? (and who controls the personnel budget?) Fire an ineffective associate editor? Other? *> assumed to be part-time for the person holding it. The EiC is not *> expected to read every paper that is published and does not generally *> make accept/reject decisions, but may get involved in process-level *> issues, such as perceived unfairness or incompetence by an associate *> editor. *> Thanks, Bob Braden From braden at ISI.EDU Fri Aug 8 11:18:25 2008 From: braden at ISI.EDU (Bob Braden) Date: Fri, 8 Aug 2008 11:18:25 -0700 (PDT) Subject: [rfc-i] Some questions about the RFC Editor restructuring plan Message-ID: <200808081818.LAA21516@gra.isi.edu> *> *> IMHO there is only a partial correspondence, because an independent *> peer review process is needed only for the Independent Stream. So I *> think there is a strong analogy between the "RFC Reviewing Editor" *> and an academic editor-in-chief, and between the RFC "Editorial Review *> Board" [RFC4846] and an academic editorial board, *but* the analogies Brian, I am trying to understand what you are saying. Looking at RFC 4846, I do not find the term "Editorial Review Board". Am I (or grep ;-)) missing something? Bob Braden *> only apply to the Independent Stream. *> *> Brian *> From hgs at cs.columbia.edu Fri Aug 8 11:37:02 2008 From: hgs at cs.columbia.edu (Henning Schulzrinne) Date: Fri, 8 Aug 2008 14:37:02 -0400 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: <200808081815.LAA21499@gra.isi.edu> References: <200808081815.LAA21499@gra.isi.edu> Message-ID: <20D9C410-2B60-426D-A95F-3AEEE7A702B7@cs.columbia.edu> On Aug 8, 2008, at 2:15 PM, Bob Braden wrote: > > > Henning, Several more questions arise from your explanation. > > *> > *> - The steering committee selects an editor-in-chief, for a > finite, non- > *> renewable term. That position is a volunteer position. The EiC > sets > > Who selects the steering committee? This differs between journals, from what I can tell. In many cases, it's like university trustees, i.e., the body is self-sustaining and nominates replacement for members that leave or reach their term limits. In other cases, the society's publication director or equivalent nominates members. (For example, the ACM SIGCOMM executive committee is effectively the steering committee for CCR.) There may even be cases where the set of associate editors elects the EiC (and where there is no steering committee at all), although I can't think of a particular journal in that category right now. In the case of the Transactions on Networking, it's a multi-society journal (ACM, IEEE ComSoc, IEEE Computer Society), and each get to designate a set of members to the steering committee, in addition to some ex-officio members, such as the EiC. > > > *> general policy (usually in discussions with the steering > committee), > *> gets involved in editorial disputes, nominates new associate > editors > *> and observes the work flow. In particular, the EiC is generally > held > *> responsible if the time-to-publish starts increasing. The > position is > > What means does the EiC have at his/her disposal to reduce the time- > to- > publish? Hire more editorial people and/or authorize overtime? (and > who controls the personnel budget?) Fire an ineffective associate > editor? Other? Some are direct managerial, such as the hiring and firing of associate editors you mention, or the establishment of procedures, such as having his or her assistant do better tracking and nagging. (Associate editors aren't paid, so there are no financial resource issues.) Usually, review, rather than production, delays are the main cause of publication delays for journals. However, the ACM ToN steering committee, on behalf of its EiC, recently had to plead for higher page budgets with the societies sponsoring the journal to reduce a publication backlog caused by having more papers accepted than the annual page budget allowed. Thus, there was no direct authority to spend more money, but rather an expectation that the EiC would ask for resources, with the help of the steering committee, which involved creating a plan and a budget proposal. This isn't that different from other parts of the real world; as department chair, I have a very limited discretionary budget, and anything non-trivial requires pleading with the dean. I still get held responsible if things don't work right, even if that's due to limited resources... > > > *> assumed to be part-time for the person holding it. The EiC is not > *> expected to read every paper that is published and does not > generally > *> make accept/reject decisions, but may get involved in process- > level > *> issues, such as perceived unfairness or incompetence by an > associate > *> editor. > *> > > Thanks, > > Bob Braden From brian.e.carpenter at gmail.com Fri Aug 8 13:45:10 2008 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sat, 09 Aug 2008 08:45:10 +1200 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: <200808081818.LAA21516@gra.isi.edu> References: <200808081818.LAA21516@gra.isi.edu> Message-ID: <489CB056.5020004@gmail.com> Bob, In my copy of 4846 that is the title of section 6. Brian On 2008-08-09 06:18, Bob Braden wrote: > *> > *> IMHO there is only a partial correspondence, because an independent > *> peer review process is needed only for the Independent Stream. So I > *> think there is a strong analogy between the "RFC Reviewing Editor" > *> and an academic editor-in-chief, and between the RFC "Editorial Review > *> Board" [RFC4846] and an academic editorial board, *but* the analogies > > Brian, > > I am trying to understand what you are saying. Looking at RFC 4846, I > do not find the term "Editorial Review Board". Am I (or grep ;-)) > missing something? > > Bob Braden > > *> only apply to the Independent Stream. > *> > *> Brian > *> > From ginoza at ISI.EDU Fri Aug 8 15:29:56 2008 From: ginoza at ISI.EDU (Sandy Ginoza) Date: Fri, 8 Aug 2008 15:29:56 -0700 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: References: <5.1.0.14.2.20080731074209.02df9b90@boreas.isi.edu> Message-ID: All, A few comments below... On Aug 7, 2008, at 3:20 AM, Olaf Kolkman wrote: > > > Bob, > > First a few answers to your questions, then a few words on what I > picked up in the hallways. > > On Jul 31, 2008, at 4:44 PM, Bob Braden wrote: >> * Please give a concise summary of how this restructuring model >> differs >> from the current model. Note that the proposed model is so >> general that it includes as >> one case the current ISOC contract with ISI for RFC Editor services. > > > This is the _first_ model of the RFC editor function. Under the > current contract ISI performs almost all of the functions indicated > in the diagram. The notable exception is that some early copy > editing is done under direct contract under contract with ISOC, > managed by the IAOC [1]. While it is true that the IAOC manages the contracts of the copy editors, the RFC Editor (currently) manages the workload and training efforts (with the ability to escalate problems to the IAD). Just an FYI: Please note that there is a notable difference between the work of the copy editor and the primary editor that works with the document/ authors until publication. The idea of hiring "commodity copy editors" was introduced in 2005-2006, while the RFC Editor was backlogged. It was thought that hiring copy editors would help increase the pace with which documents were published. When the RFC Editor project was put out to bid, the copy editors were separated from the RFC Editor contract to reduce costs. I do not have an understanding of how the copy editor/primary editor relationship will be handled in the proposed structure model (e.g., will the copy editing and editing be reunified in the production house; will the copy editors remain a separable function and managed by the production house and/or the "RFC Editor"; etc.), but I hope the intent is not to rely more heavily on the copy editors. Please remember the initial sense of anger expressed by the community when the copy editors were introduced because the RFC Editor was "over editing". We currently have 3 active copy editors working with the RFC Editor. Each of them has varying levels of IETF- and RFC-specific knowledge, and each of them returns a different level of copy-edited product. They correct grammar/spelling errors and bring the primary editor's attention to problematic areas on a regular basis. However, it is the primary editor that then reviews the copy edited document, filters through the edits (often re-editing), interacts with the authors to clarify questions, reviews, verifies, and updates IANA- related text, checks formal languages, applies their judgement based on IETF- and RFC-specific policies/tendencies, etc.. There is a *significant* difference between the copy edited document and the document that is provided to the authors for review during AUTH48. Sandy > > [1] For the benefit of folk not familiar with this: an example of > such contract can be found at http://iaoc.ietf.org/documents/ > CopyEdit_Contract.pdf From paul.hoffman at vpnc.org Fri Aug 8 15:59:27 2008 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Fri, 8 Aug 2008 15:59:27 -0700 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: References: <5.1.0.14.2.20080731074209.02df9b90@boreas.isi.edu> Message-ID: At 3:29 PM -0700 8/8/08, Sandy Ginoza wrote: >While it is true that the IAOC manages the contracts of the copy >editors, the RFC Editor (currently) manages the workload and training >efforts (with the ability to escalate problems to the IAD). That is how it should be. The person responsible for the copy editing should be doing both training and review of the copy editors. >Please note that there is a notable difference between the work of >the copy editor and the primary editor that works with the document/ >authors until publication. This, too, is how it should be. >Please remember the initial sense of anger expressed by the >community when the copy editors were introduced because the RFC >Editor was "over editing". This may have been due to too little training of the copy editors and/or too little oversight of them. >We currently have 3 active copy editors working with the RFC Editor. >Each of them has varying levels of IETF- and RFC-specific knowledge, >and each of them returns a different level of copy-edited product. This does not sound like a good situation. Shouldn't there be a small bit of training to bring them all up to the correct speed? Most professional copy editors can learn these types of things in a small number of hours, approximately the time it would take to copy edit maybe two RFCs. The take-away here is that, in the proposed structure, the Production House is responsible for the copy editing *and* for making sure the copy editing is done well (as well as other tasks, of course). --Paul Hoffman, Director --VPN Consortium From olaf at NLnetLabs.nl Mon Aug 11 04:34:43 2008 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Mon, 11 Aug 2008 13:34:43 +0200 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: References: <5.1.0.14.2.20080731074209.02df9b90@boreas.isi.edu> Message-ID: <09EC0948-47C3-4619-AF10-AEA797DCF424@nlnetlabs.nl> Aaron, Thanks for the reply. It very clearly points out the risk: > Any changes will have an associated cost and consume > resources (e.g., creating or modifying editorial standards, software, > or process descriptions). If the RFC Editor doesn't control > resources, they can only criticize and suggest, not **be responsible** > for implementing improvements. This will create a three-way tension > between the Production House (who needs to manage to cost and > contractual agreements), the IAOC/IAD (who holds sets the contracts > and who, btw, isn't shown on the diagram at [1]), and the RFC Editor > (who has neither contract nor funding to push the Production House in > a desired direction). However, to me personally, this is still about the implementation of the model. In fact in the current model that is explicitly stated: > The model is constructed in such a way that it allows for all these > functions to be implemented jointly or under different contracts. > In fact, a bidder could put together a proposal that includes one or > more subcontractors. Since the reporting structure would depend on > how the manner that the contracts are awarded, they are subject to > change over time. As a result, the model does only describe > responsibilities, procedures, and process. The exact implementation > is a responsibility of the IAOC. On the other hand, I have heard sufficient comments that I think some clarification is needed. So my (personal) straw-man would be to add a section. Implementation Guidance The RFC Editor will need to be enforced to direct the Production house to implement measures to maintain the series consistency and quality. The IAPC will need to ascertain that appropriate vehicles are in place for this. Without prejudice to other possible implementations of this model the IAOC is requested to specifically investigate the possibilities where the RFC Editor and the Production house are awarded as one single contract or the Production house is a subcontractor to the RFC Editor. I realize that this is pushing addressing of the real problem forward, but I hope it provides sufficient early warning while maintaining a consistent and flexible model. Would this work / address some of your worries? --Olaf For context this is the full thread, no further comments below. On Aug 8, 2008, at 4:03 PM, Aaron Falk wrote: > > On Aug 7, 2008, at 6:20 AM, Olaf Kolkman wrote: > >>> * The (new) RFC Editor position is implied to be a manager and have >>> responsibilities, yet this position has no authority. >>> Responsibility >>> without authority is a well-known "bog". >> >> >> I realize that there is a risk that my answer will start a debate >> about semantics. >> >> Within the IETF community there are a number of positions (ADs, WG- >> chairs, IAB membership, Nomcom membership) where by taking >> responsibility folk are being granted authority. And although folk >> in those positions have a small toolkit if it comes to the available >> carrots and sticks this all seems to work to some extend. >> >> It is up to the parties involved in the model, including the IAB and >> IAOC, to grant the authority to the RFC editor. I hear you pointing >> out that there are risks that that may fail. > > Hmm, well, the ability for an RFC Editor to be responsible for series > continuity, style management, and errata is going to be very different > based on whether that person has financial control over the production > process. Any changes will have an associated cost and consume > resources (e.g., creating or modifying editorial standards, software, > or process descriptions). If the RFC Editor doesn't control > resources, they can only criticize and suggest, not **be responsible** > for implementing improvements. This will create a three-way tension > between the Production House (who needs to manage to cost and > contractual agreements), the IAOC/IAD (who holds sets the contracts > and who, btw, isn't shown on the diagram at [1]), and the RFC Editor > (who has neither contract nor funding to push the Production House in > a desired direction). If the RFC Editor has any authority at all, > this seems like a potential mess of unclear management authority. If > they don't and provide only an advisory role, I think their ability to > **be responsible** for maintaining the quality of the series is going > to be very limited. > > --aaron (also wearing no particular hats) > > [1] http://www.iab.org/documents/resources/RFC-Editor-Model.html > _______________________________________________ > rfc-interest mailing list > rfc-interest at rfc-editor.org > http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 235 bytes Desc: This is a digitally signed message part Url : http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20080811/6cb84310/PGP.bin From paul.hoffman at vpnc.org Tue Aug 12 20:24:46 2008 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Tue, 12 Aug 2008 20:24:46 -0700 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: <09EC0948-47C3-4619-AF10-AEA797DCF424@nlnetlabs.nl> References: <5.1.0.14.2.20080731074209.02df9b90@boreas.isi.edu> <09EC0948-47C3-4619-AF10-AEA797DCF424@nlnetlabs.nl> Message-ID: At 1:34 PM +0200 8/11/08, Olaf Kolkman wrote: >On the other hand, I have heard sufficient comments that I think >some clarification is needed. So my (personal) straw-man would be to >add a section. > > Implementation Guidance > > The RFC Editor will need to be enforced to direct the Production house > to implement measures to maintain the series consistency and quality. The > IAPC will need to ascertain that appropriate vehicles are in >place for this. > > Without prejudice to other possible implementations of this model >the IAOC is > requested to specifically investigate the possibilities where the >RFC Editor > and the Production house are awarded as one single contract or >the Production > house is a subcontractor to the RFC Editor. > That first sentence is hard to parse. How about "The RFC Editor has the authority to direct the Production House to implement measures to maintain the series consistency and quality."? --Paul Hoffman, Director --VPN Consortium From john+rfc at jck.com Wed Aug 13 17:25:03 2008 From: john+rfc at jck.com (john+rfc@jck.com) Date: Wed, 13 Aug 2008 20:25:03 -0400 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: References: Message-ID: <930733F737260F28266EB72A@[192.168.1.110]> --On Wednesday, 12 Aug 2008 20:24:46 -0700 Paul Hoffman wrote: > That first sentence is hard to parse. How about "The RFC > Editor has the authority to direct the Production House to > implement measures to maintain the series consistency and > quality."? "authority" exists only if the RFC Editor can fire or penalize the Production House if they do not comply and comply in a satisfactory way. If the contracts are separate, one either needs to give the RFC Editor the ability to direct the IAD to direct the Production House or the model needs to include some other mechanism to give "authority" and/or "direct" some teeth. Remember that, especially if the contracts are awarded separately, the Production House may be a for-profit (and potentially "low-bid" activity, with every incentive to control costs in ways that might be incompatible with the RFC Editor's norms for quality. john From tomasz.pelczar at yahoo.com Thu Aug 14 14:35:06 2008 From: tomasz.pelczar at yahoo.com (Tomasz Pelczar) Date: Thu, 14 Aug 2008 14:35:06 -0700 (PDT) Subject: [rfc-i] rfc-interest Digest, Vol 47, Issue 7 In-Reply-To: Message-ID: <610317.45689.qm@web57413.mail.re1.yahoo.com> --- On Thu, 8/14/08, rfc-interest-request at rfc-editor.org wrote: From: rfc-interest-request at rfc-editor.org Subject: rfc-interest Digest, Vol 47, Issue 7 To: rfc-interest at rfc-editor.org Date: Thursday, August 14, 2008, 7:00 PM Send rfc-interest mailing list submissions to rfc-interest at rfc-editor.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest or, via email, send a message with subject or body 'help' to rfc-interest-request at rfc-editor.org You can reach the person managing the list at rfc-interest-owner at rfc-editor.org When replying, please edit your Subject line so it is more specific than "Re: Contents of rfc-interest digest..." Today's Topics: 1. Re: Some questions about the RFC Editor restructuring plan (john+rfc at jck.com) ---------------------------------------------------------------------- Message: 1 Date: Wed, 13 Aug 2008 20:25:03 -0400 From: john+rfc at jck.com Subject: Re: [rfc-i] Some questions about the RFC Editor restructuring plan To: rfc-interest at rfc-editor.org Message-ID: <930733F737260F28266EB72A@[192.168.1.110]> Content-Type: text/plain; charset=us-ascii; format=flowed --On Wednesday, 12 Aug 2008 20:24:46 -0700 Paul Hoffman wrote: > That first sentence is hard to parse. How about "The RFC > Editor has the authority to direct the Production House to > implement measures to maintain the series consistency and > quality."? "authority" exists only if the RFC Editor can fire or penalize the Production House if they do not comply and comply in a satisfactory way. If the contracts are separate, one either needs to give the RFC Editor the ability to direct the IAD to direct the Production House or the model needs to include some other mechanism to give "authority" and/or "direct" some teeth. Which of the RFC "letters" to the human brains within the those, which are still functional, but also the background of the RFC nr.1, like mstr. T. Edison first "patent" was the best in case of the fundamental issues to implement the issues within the TCP, OSI, IBM standards. If the first number(s) or the most important description(s) (like Stevens, Wright or Dijkstra etc) cannot take the responsibility (etc) then the best authority must take the experimental "status quo" ... Remember that, especially if the contracts are awarded separately, the Production House may be a for-profit (and potentially "low-bid" activity, with every incentive to control costs in ways that might be incompatible with the RFC Editor's norms for quality. All the best from the sunny Krak?w: Tom john ------------------------------ _______________________________________________ rfc-interest mailing list rfc-interest at rfc-editor.org http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest End of rfc-interest Digest, Vol 47, Issue 7 ******************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20080814/15c7a75e/attachment.html From olaf at NLnetLabs.nl Mon Aug 25 08:55:20 2008 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Mon, 25 Aug 2008 17:55:20 +0200 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: <09EC0948-47C3-4619-AF10-AEA797DCF424@nlnetlabs.nl> References: <5.1.0.14.2.20080731074209.02df9b90@boreas.isi.edu> <09EC0948-47C3-4619-AF10-AEA797DCF424@nlnetlabs.nl> Message-ID: Folk, I have reread the thread and we are at a point where I think a few minor details have be addressed, such as changing the name from the Independent Stream Approver to the Independent Submission Editor. I also have the feeling that the overall distribution of tasks within the 4 functions of the model is not contentious. At least nobody argued against that. The open issues are mostly doubts about the implementation of the model, mostly with respect to the interactions between the various functions. In particular there was a question about the instruments hat the RFC Editor has to its disposal to assume responsibility of over the series in case the production house is not cooperative. Although I understand the question and its background I am not sure wether the model should address those explicitly or not. One could address that by giving the IAOC some implementation guidance (I've suggested some wording in the thread). However the question is if that would provide the IAOC with to little maneuvering space. Another way to address these issues is by explicitly recognizing that all roles (except maybe the publishing house, which is the most mechanical of the functions) are subject to some sort of policy oversight by the IAB (cf RFC4844 sect 3.4). I am trying to wear a moderator hat and keep a somewhat neutral stance although in all honesty I think that the model as written currently allows to address the issues during implementation, where they should be addressed. Please read the archive (starting at: http://mailman.rfc-editor.org/pipermail/rfc-interest/2008-May/000581.html) and weigh in if you have an informed opinion. We need to drive this to closure. --Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 235 bytes Desc: This is a digitally signed message part Url : http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20080825/ac5c7da0/PGP.bin From paul.hoffman at vpnc.org Mon Aug 25 10:19:44 2008 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Mon, 25 Aug 2008 10:19:44 -0700 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: References: <5.1.0.14.2.20080731074209.02df9b90@boreas.isi.edu> <09EC0948-47C3-4619-AF10-AEA797DCF424@nlnetlabs.nl> Message-ID: At 5:55 PM +0200 8/25/08, Olaf Kolkman wrote: >...in all honesty I think that the model as written currently allows >to address the issues during implementation, where they should be >addressed. Agree. >Please read the archive (starting at: >http://mailman.rfc-editor.org/pipermail/rfc-interest/2008-May/000581.html) >and weigh in if you have an informed opinion. I was part of a team that bid on the first RFP, and have been following this discussion closely, so I consider that "informed". >We need to drive this to closure. Agree. --Paul Hoffman, Director --VPN Consortium From housley at vigilsec.com Tue Aug 26 07:23:17 2008 From: housley at vigilsec.com (Russ Housley) Date: Tue, 26 Aug 2008 10:23:17 -0400 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: References: <5.1.0.14.2.20080731074209.02df9b90@boreas.isi.edu> Message-ID: <200808261423.m7QENLQZ026687@boreas.isi.edu> Aaron: >Hmm, well, the ability for an RFC Editor to be responsible for series >continuity, style management, and errata is going to be very different >based on whether that person has financial control over the production >process. Any changes will have an associated cost and consume >resources (e.g., creating or modifying editorial standards, software, >or process descriptions). If the RFC Editor doesn't control >resources, they can only criticize and suggest, not **be responsible** >for implementing improvements. This will create a three-way tension >between the Production House (who needs to manage to cost and >contractual agreements), the IAOC/IAD (who holds sets the contracts >and who, btw, isn't shown on the diagram at [1]), and the RFC Editor >(who has neither contract nor funding to push the Production House in >a desired direction). If the RFC Editor has any authority at all, >this seems like a potential mess of unclear management authority. If >they don't and provide only an advisory role, I think their ability to >**be responsible** for maintaining the quality of the series is going >to be very limited. You are arguing for a tighter coupling between the RFC editor and the Production house based on a good principle: do not make some one responsible for things that they have no authority to influence. This a good principle, but I thin you are reading more into the responsibility than was intended. The RFC Editor is responsible for the series continuity, style management, and errata. To me that involves planning, style guides, and so on. I do not see this a review every RFC before it is posted level of oversight. I would expect that type of review to be provided by a quality control function in the production house. I would also expect the RFC Editor to provide design review for proposed enhancements to web site design and tools development. Again, this does not impact the day-to-day operation of production house, but it does offer the RFC Editor the opportunity to steer things that impact the overall series. If a production house contractor was ignoring all of the input from a loosely-coupled RFC Editor, the I would expect the IAD and IAOC to take contractual actions. There is a parallel in today's structure, and these are the same actions that would be taken today if the IAB was very unhappy with the performance of the current RFC Editor. The IAB has oversight roles today, and as far as I can tell the community is quite happy with the manner that the IAB performs them, and the IAB does not need a tightly-coupled relationship in order to perform them. Russ From ah at tr-sys.de Tue Aug 26 12:26:40 2008 From: ah at tr-sys.de (Alfred =?hp-roman8?B?SM5uZXM=?=) Date: Tue, 26 Aug 2008 21:26:40 +0200 (MESZ) Subject: [rfc-i] draft-rfc-image-files-00 Message-ID: <200808261926.VAA28567@TR-Sys.de> Hello, your new I-D, draft-rfc-image-files-00, seems to be a good idea and, IMHO, it comes at the right moment (see below). First of all, I appreciate the idea of picking the best of what we already have (this should make the proposal acceptable even to dedicated traditionalists), and come up with a solution that hopefully makes the job of authors and the RFC Editor team easier, when full-fledged images really are needed for clarity. The larger challenge is placed on the side of the tools to manage the new files -- at the I-D repository plus datatracker, at the RFC Editor site, and at tools.ietf.org --, but that has to be resolved and done only once... As noted in the draft, companion rfcnnnn.pdf files in the past were a source of trouble and inconsistencies. (For instance, didn't one of the most recent such .pdf show an earlier publication month than the 'official' RFC, i.e. rfcnnnn.txt ?) The solution envisioned in the draft has the smart property of being consistent with the traditional (non-interactive) repository mirroring and synchronization procedures, by simply placing an additional new file type in the directories. I suggest that the proposed changes for the RFC front matter (4.3) should be closely coordinated with the current IAB proposal, draft-iab-streams-header-boilerplates, to avoid racing conditions between these two drafts during the document evolution and publication processes, and for clarity and simplicity for the audience. The idea of requesting a table of Figures should be pursued even more, also in the absence of such new companion .pdf file. Supplying such a list regularly should help avoid the irregular figure numbering patterns that can be observed in contemporary I-Ds, and -- admittedly to a much lesser extent -- in RFCs. [ If I don't err, there recently was a WG draft in IETF LC containing (only) Figures 4, 5, 8, and 9 (or similar). :-) ] Finally, two notes on textual flaws I found: (1) Section 4.3 s/lefthand footer/lefthand running header/g [ Note that the "RFC nnnn" appears in the upper left corner of pg. 2 ff. of RFCs, not in the running page footers. :-) ] (2) Section 6 First line: s/acheme/scheme/ Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah at TR-Sys.de | +------------------------+--------------------------------------------+ From rpelletier at isoc.org Tue Aug 26 13:02:29 2008 From: rpelletier at isoc.org (Ray Pelletier) Date: Tue, 26 Aug 2008 16:02:29 -0400 Subject: [rfc-i] Some questions about the RFC Editor restructuring plan In-Reply-To: <200808261423.m7QENLQZ026687@boreas.isi.edu> References: <5.1.0.14.2.20080731074209.02df9b90@boreas.isi.edu> <200808261423.m7QENLQZ026687@boreas.isi.edu> Message-ID: +1 Ray On Aug 26, 2008, at 10:23 AM, Russ Housley wrote: > Aaron: > >> Hmm, well, the ability for an RFC Editor to be responsible for series >> continuity, style management, and errata is going to be very >> different >> based on whether that person has financial control over the >> production >> process. Any changes will have an associated cost and consume >> resources (e.g., creating or modifying editorial standards, software, >> or process descriptions). If the RFC Editor doesn't control >> resources, they can only criticize and suggest, not **be >> responsible** >> for implementing improvements. This will create a three-way tension >> between the Production House (who needs to manage to cost and >> contractual agreements), the IAOC/IAD (who holds sets the contracts >> and who, btw, isn't shown on the diagram at [1]), and the RFC Editor >> (who has neither contract nor funding to push the Production House in >> a desired direction). If the RFC Editor has any authority at all, >> this seems like a potential mess of unclear management authority. If >> they don't and provide only an advisory role, I think their ability >> to >> **be responsible** for maintaining the quality of the series is going >> to be very limited. > > You are arguing for a tighter coupling between the RFC editor and the > Production house based on a good principle: do not make some one > responsible for things that they have no authority to > influence. This a good principle, but I thin you are reading more > into the responsibility than was intended. > > The RFC Editor is responsible for the series continuity, style > management, and errata. To me that involves planning, style guides, > and so on. I do not see this a review every RFC before it is posted > level of oversight. I would expect that type of review to be > provided by a quality control function in the production house. I > would also expect the RFC Editor to provide design review for > proposed enhancements to web site design and tools > development. Again, this does not impact the day-to-day operation of > production house, but it does offer the RFC Editor the opportunity to > steer things that impact the overall series. > > If a production house contractor was ignoring all of the input from a > loosely-coupled RFC Editor, the I would expect the IAD and IAOC to > take contractual actions. There is a parallel in today's structure, > and these are the same actions that would be taken today if the IAB > was very unhappy with the performance of the current RFC > Editor. The IAB has oversight roles today, and as far as I can tell > the community is quite happy with the manner that the IAB performs > them, and the IAB does not need a tightly-coupled relationship in > order to perform them. > > Russ > > _______________________________________________ > rfc-interest mailing list > rfc-interest at rfc-editor.org > http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest From hagens at ISI.EDU Wed Aug 27 12:44:19 2008 From: hagens at ISI.EDU (Alice Hagens) Date: Wed, 27 Aug 2008 12:44:19 -0700 Subject: [rfc-i] xml2rfc FAQ available Message-ID: Greetings, Frequently asked questions (and answers) about xml2rfc have been posted here: http://xml.resource.org/xml2rfcFAQ.html I hope it's helpful to new users. Please send me any corrections or additions. Thank you. Alice for the RFC Editor From nobody at xyzzy.claranet.de Wed Aug 27 15:17:21 2008 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Thu, 28 Aug 2008 00:17:21 +0200 Subject: [rfc-i] xml2rfc FAQ available References: Message-ID: Alice Hagens wrote: > http://xml.resource.org/xml2rfcFAQ.html Great. As always the demon question, *where* is the text/plain output for rfcmarkup, or the XML source to create it ? The audience of my IETF tools page are Lynx users, any other stoneage browser not supporting CSS, or modern mobile devices with their own restrictions. Without TXT version common tasks such as rfcdiff don't work. Without XML folks insisting on PDF in addition to HTML (please don't ask why, I have not the faintest idea) cannot use Julian's tools. Julian's tools support lots of other magic, all directly on the XML, avoiding the lossy TXT step for the various IETF tools. --- 3.1 bullet 1 s/at the top/DTD subset at the top/ (terminology not, "at the top" is IMO too vague). The note "choose uppercase" is IMHO unnecessary: Whatever folks pick, it has to match the use in the references. A reference has to be used in the body (otherwise this triggers a warning for strict). The entity name is *unrelated* to the fragment identifier determined by the anchor in the imported bibxml snippet, that is something confusing authors: Entity name and fragment id. *appear* to be related for RFCs. --- 3.1 bullet 2: limitation. I didn't know that this fails for text output, that's a bug: For abc I expect xyz abc or similar, not only abc. And in the simple case it works, I get 123 as text, not an empty string. --- 3.10 Same issue as for , something with section 2 is not as it should be for the purposes of rfcmarkup. --- 3.11 Brilliant, I didn't know format="title". --- 4.4 Ditto most list details in chapter 4, thanks. --- 5.1 outside of
, are you sure that this is valid XML based on the DTD ? There are situations when I use the W3C validator... --- 6.5 Interesting, I have to test inline="no", it sounds like a plan to use in a good way. --- 1.4 Maybe add self-references to all formats of the FAQ (HTML, TXT, XML) here. For drafts and RFCs everybody knows where that is, but the FAQ and the Checklist are no ordinary numbered I-Ds. The 2006 slides exist also in a human readable format, not only as proprietary document format: Eager to add a rfcmarkup link to the TXT version on my IETF tools page, Frank From ah at tr-sys.de Fri Aug 29 01:06:55 2008 From: ah at tr-sys.de (Alfred =?hp-roman8?B?SM5uZXM=?=) Date: Fri, 29 Aug 2008 10:06:55 +0200 (MESZ) Subject: [rfc-i] draft-crocker-rfc-media-00 Message-ID: <200808290806.KAA03014@TR-Sys.de> Dave, thanks for the slight generalization performed by your I-D, draft-crocker-rfc-media-00. Allowing to Split *the* image file into several files per 'image' will certainly further alleviate the task of RFC authors, the RFC Editor, and tools authors. However, for the latter folks it would perhaps be *much* easier if the draft posed the requirement that the content of each image file must be 'contiguous' and anchored at a single place in the base document, to be able to insert the whole image file there. (Isn't that what xml2rfc already does?) Hence, I suggest to *require* multiple image files if multiple anchors are needed. Also, adding Section 1.2, "Goals", is an important step, in general, and to avoid endless circular discussions. (The lack of similar rationale is a major deficiency in the other current RFC-Ed I-D, the RFC Errata draft, for instance.) Unfortunately, the time pressure in generating this -00 version is very much visible, and the notes below are intended to help get rid of the inconsistencies and textual flaws. (BTW: Most nits have been faithfully inherited ...) (1) General: running page titles s/Email Architecture/Images in RFCs/ :-) (2) General: image file --> image file(s) The generalization has not been performed consistently. Many parts of the text still refer to "the image file" (in singular form) where "the image files" or "the image file(s)" or "an image file" should be mentioned insted. For brevity, I do not list all instances of this flaw, but only some important ones, nearby to other changes proposed. (3) General: PDF --> {standard format} The generalization for the standard format has not been performed consistently. Some phrases still quote PDF, or the specifications for PDF, or perhaps PDF specific tools. Furthermore: If more than one such format is going to be allowed, should we really request that all image files for an RFC use the *same* format, or is that a needless restriction? The present text seems to generally assume a single format. (4) Section 1, 3rd paragraph The draft says: The three versions of an RFC using .txt+.pdf+.ps encoding are in separate files in the primary RFC repository | (http://www.rfc-editor.org/rfc/"), with suffixes ".txt", ".pdf", and ".ps". The RFC Editor search engine returns links to all three versions when they are present in the repository. This is misleading and wrong. The primary RFC repository still is the RFC-Editor FTP site, and the RFC Editor search engine in fact eventually returns links to that site: ftp://ftp.rfc-editor.org/in-notes/ ^^^ ^^^ ^^^^^^^^ (5) Section 2 (5.1) 1st paragraph Mismatched curly braces: {{standard image} ^^ ^ For consistency with later text, please remove one '{'. (5.2) 2nd paragraph I suggest to add more precision to the internal reference, by changing: The base file may be formatted exactly like current ASCII RFCs, with three minor exceptions described below. [...] --- ^^^^^ The base file may be formatted exactly like current ASCII RFCs, with three minor exceptions described in Section 4. [...] ^^^^^^^^^^^^ The idea of optionally using xml2rfc format requires more thought. For instance, placing such files as .txt into the RFC repository (Section 7) will certainly confuse readers and break tools. (5.3) 3rd paragraph An instance of (2) above: The intellectual property boilerplate in the base file ("Rights in | Contributions BCP 78, RFC 4748 [RFC4748] ) would apply equally to the vv ^ | image file. [...] --- The intellectual property boilerplate in the base file ("Rights in | Contributions BCP 78, RFC 4748 [RFC4748]) would apply equally to the vvvvv ^ | image file(s). [...] (5.4) 5th paragraph -- issue (3) The final conclusion there has been left unchanged, still arguing in favor of PDF (only). This should be modified to actually allow PNG, GIF, etc., instead, as apparently has been intended by the introduction of the meta- identifiers "{image format}" / "{standard image}" (etc.). (6) Section 3 (6.1) 1st paragraph -- issue (3) The draft says: Each image would be in a single {image format} file, containing only | that image and consistent with the description in [RFC3778] and vvvvvvvvvvvv ^^^^^^^^^ | defined in [ISO32000-1]. [...] These references are for PDF only. Hence, that text needs amendments. (6.2) 2nd paragraph -- issue (3) Similarly, ... vvv | Future experience may require published guidelines on PDF-generating software that claims to satisfy {image format}{image format} but does not. ... is inconsistent internally and with the generalization . (6.3) 3rd paragraph -- nit Please add the missing final period to this paragraph. (6.4) 5th paragraph -- issue (2), plus wrong pointer [...]. The page number of the end-of-RFC boilerplate (in the base RFC file) would be the first page number | after those in the image file. Each page of the image file would contain the same headers and footers as the base file, except for one | change in the footer, suggested below. --- ^^^^^^ [...]. The page number of the end-of-RFC boilerplate (in the base RFC file) would be the first page number | after those in the image file(s). Each page of the image file(s) ^^^ ^^^ would contain the same headers and footers as the base file, except | for one change in the header, suggested below. ^^^^^^ [ See item (7.1) below for rationale! ] (6.5) 6th paragraph -- issue (2), plus poor language "They may be ... or it may use ..." seems to be ppor language. Proposal: Figures included in the image file would have to be labeled in a fashion that facilitated referencing from the base RFC. They may be numeric and monotonic or it may use textual image names. [...] --- Figures included in the image file would have to be labeled in a | fashion that facilitated referencing from the base RFC. The labels vvvvvvvvvv ^^^^^^^^^^ | may be numeric and monotonic or consist of textual image names. [...] (7) Section 4.2 (7.1) 1st paragraph -- grammar ... should immediately following the Table of Contents, ... --- ^^^ | ... should immediately follow the Table of Contents, ... (7.2) Example for ToC + list of Figures RFC page numbering starts with no. 1 for the front page, and the word "follows" is rather questionable for page 1 when used in the Figures section (perhaps also on page 1, or even on page 2). Therefore, using page 1 for Section 1 in the example seems to be rather unusual, and perhaps even confusing. Therfore, I suggest using page 2 (at least) instead: Table of Contents | 1. Introduction ............................................... 1 --- ^ Table of Contents | 1. Introduction ............................................... 2 ^ ... and (at the bottom) ... | (Page 1 follows) --- ^ | (Page 2 follows) ^ (8) Section 4.3 (8.1) 1st paragraph As already noted in a post to rfc-interest at rfc-editor.org, the "RFC nnnn" appears in the upper left corner of RFC pages, not in the footer. Also, the quotes do not match, and white space introduced irregularly after the second '/'. Therefore, the text should be corrected: The header line "Request for Comments: nnnn" in the base file could be changed to "Request for Comments: nnnn/Base". For consistency, | the lefthand footer could become "RFC nnnn/Base". The lefthand ^^^^^^ | footer in the image file could then be: "RFC nnnn/ {Image Name}. ---^^^^^^ ^^^ ^^ The header line "Request for Comments: nnnn" in the base file could be changed to "Request for Comments: nnnn/Base". For consistency, | the lefthand running header could become "RFC nnnn/Base". The ^^^^^^^^^^^^^^ | lefthand running header in the image file could then be: ^^^^^^^^^^^^^^ | "RFC nnnn/{Image Name}". ^^ ^^^ [ Note: the final string in quotes should be forced into one line for clarity. ] (8.2) 3rd paragraph -- improvement I suggest the following improvement for clarity and precision: The following sentence could be placed in the "Status of this Memo" section: "This RFC is a composite of this base file and {image format} image files." --- The following sentence could be placed in the "Status of this Memo" | section: "This RFC is a composite of this base file and M {image | format} image file[s]." ^^^ ^^^ ... where 'M' denotes the actual number of image files for that RFC, and '[s]' is to be omitted iff M==1. Further, it might be more versatile to allow a mix of file type for the image files; to support this, the text should be simplified: The following sentence could be placed in the "Status of this Memo" | section: "This RFC is a composite of this base file and M image | file[s]." ^^^ ^^^^^^^^ (9) Section 5 -- item (2) In the last sentence, please change: ... figures in the image file, ... --- | ... figures in an image file, ... ^^ (10) Section 6 -- nits Please add a trailing period to implication #2. Please remove the double trailing period after implication #7. (11) Section 7, 2nd paragraph -- item (2) Minimal change: If a {image format} image file exists along with a base ASCII RFC, then RFCs in any other format (e.g., complete {image format} files, HTML, or Postscript) remain supplemental, with the reader taking responsibility for assuring that they are equivalent to the base RFC and image file. [...] --- v v ) If {image format} image files exists along with a base ASCII RFC, then RFCs in any other format (e.g., complete {image format} files, HTML, or Postscript) remain supplemental, with the reader taking responsibility for assuring that they are equivalent to the base RFC and image file. [...] Further, the considerations at the end of (3) and (8.2) above might be applicable as well. (12) Discussion It would be nice to have a note included in the draft (near the front matter or the Authors section), pointing to the rfc-interest at rfc-editor.org mailing list for discussion of the draft. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah at TR-Sys.de | +------------------------+--------------------------------------------+