From nobody at xyzzy.claranet.de Wed Jun 4 07:59:16 2008 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Wed, 4 Jun 2008 16:59:16 +0200 Subject: [rfc-i] RFC Editor Structure References: <743CAA1F-833E-4BB0-91FD-CC864E01464B@nlnetlabs.nl> Message-ID: Olaf Kolkman wrote: > The proposed model is posted on the RFC interest list, see > http://mailman.rfc-editor.org/pipermail/rfc-interest/2008-May/000581.html > and made available through > http://www.iab.org/documents/resources/RFC-Editor-Model.html Thanks for info. Some quick observations while looking at the picture of your model: You don't cover the rather convoluted interactions between IESG and "ISS", to fix that please sort the "stream" columns like that: IAB | IETF | community | IRTF. What does "selected by the community and confirmed by the IAB" actually mean, is it the same idea as for area directors, i.e. NomCom representing a random set of volunteers from visitors of three out of five recent IETF meetings ? Why should there be two persons - new "ISS" and new RFC-editor - instead of one ? In what way would a new "ISS" selected by the NomCom be really independent from IETF / IESG considerations, which is the whole point of this "independent" escape hatch as noted two years ago in the RFC 4844 discussions by John Klensin ? RFC number assignment should be the privilege of the RFC editor, not of some "outsourced" RFC production entity. This used to be great magic in the past, and it is a completely subjective magic. Moving some "RFC publisher" functions to the IETF secretariat could make sense, if that is about maintaining a high traffic Web server with tricky forms. But the quality of some IETF Web server forms is not yet up to the standard of some RFC editor forms. Working Web forms can't be expensive, please don't try to fix it if it is not broken. Frank From braden at ISI.EDU Wed Jun 4 13:33:44 2008 From: braden at ISI.EDU (Bob Braden) Date: Wed, 4 Jun 2008 13:33:44 -0700 (PDT) Subject: [rfc-i] RFC Editor Structure Message-ID: <200806042033.NAA05882@gra.isi.edu> Dear hmdmhdfmhdjmzdtjmzdtzktdkztdjz, You wrote: *> *> Thanks for info. Some quick observations while looking at the *> picture of your model: You don't cover the rather convoluted *> interactions between IESG and "ISS", to fix that please sort See RFC 3932. *> the "stream" columns like that: IAB | IETF | community | IRTF. I am not aware of any implied ordering, and I don't know what it would mean. *> *> RFC number assignment should be the privilege of the RFC editor, *> not of some "outsourced" RFC production entity. This used to be *> great magic in the past, and it is a completely subjective magic. It is not a "privilege", but a duty. And not exactly magic, but the community likes it that RFC 2822 was an update to RFC 822, for example. Not an accident, though Joyce used to like to pretend it was. The RFC Editor organization believes that RFC number assignment is inextricably bound with the production process, so it would make little sense to separate these functions. This assumes that the RFC publication model continues to use late binding for RFC numbers, as it always has. Another choice (which I believe has some serious flaws) would be to change to early RFC number binding -- say, RFC numbers are assigned by the IESG before the document enters the publication process. The IESG could go as far as it wanted towards structuring the number space (and how long would it be before a Dewey decimal numbering scheme appeared?). Bob Braden From brian.e.carpenter at gmail.com Wed Jun 4 20:28:20 2008 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Thu, 05 Jun 2008 15:28:20 +1200 Subject: [rfc-i] RFC Editor Structure In-Reply-To: <743CAA1F-833E-4BB0-91FD-CC864E01464B@nlnetlabs.nl> References: <743CAA1F-833E-4BB0-91FD-CC864E01464B@nlnetlabs.nl> Message-ID: <48475D54.6080200@gmail.com> Hi, 1. What's the funding model for the "Independent Stream Supervisor"? That's not a job title that is very inspiring, and if it's a volunteer position, it would seem very unlikely to me that we'll find reliable and conscientious individuals willing to do it in the long term. I don't see it as comparable to an unpaid Editorship of an academic journal, for example, unless it is described in much more exciting language. But it also seems hard to justify as a funded service on its own. "Expenses to support the administrative operation of the Independent Stream Supervisor selected in this manner would be part of the IASA budget." Well, that is a very explicit extension of the scope of IASA beyond IETF activities. I'd want to see a consensus call on that. 2. Also re the Independent Stream: "...no changes to the Editorial Board are being proposed." Let's discuss that. I don't like the current degree of secrecy around the way the EB reviews independent submissions. Especially if we end up spending IASA money explicitly for this stream, I'd like to see all EB reviews being made public. People who want to publish via confidential peer review have lots of other places to try. 3. I find it hard to see any advantage of making the "RFC Editor" job independent of the contractor for the "RFC Production" function. Funding it as a separate activity seems to add cost and complexity for no particular reason. I think it should just be a part of the "RFC Production" contract, with some conditions to ensure responsiveness to the community. 4. I suggest that total efficiency will be greater if the RFC Publisher function is part of the Secretariat IT service, which already includes web site support and I-D publication. 5. The responsiblities of the RFC Publisher need to include maintenance of the various plain text and hyperlinked indexes currently provided at rfc-editor.org. I believe this strengthens my previous comment. Brian From braden at ISI.EDU Thu Jun 5 11:07:54 2008 From: braden at ISI.EDU (Bob Braden) Date: Thu, 5 Jun 2008 11:07:54 -0700 (PDT) Subject: [rfc-i] IPv6 support in place Message-ID: <200806051807.LAA06222@gra.isi.edu> We believe that the RFC Editor web site is now live using IPv6 (at last!). It has had somewhat minimal testing, so we invite you to break it ;-). I am told that there are AAAA records for www.rfc-editor.org and rfc-editor.org. Bob Braden for the RFC Editor From braden at ISI.EDU Thu Jun 5 11:38:11 2008 From: braden at ISI.EDU (Bob Braden) Date: Thu, 5 Jun 2008 11:38:11 -0700 (PDT) Subject: [rfc-i] RFC Editor Structure Message-ID: <200806051838.LAA06286@gra.isi.edu> *> *> 2. Also re the Independent Stream: "...no changes to the Editorial *> Board are being proposed." Let's discuss that. I don't like the *> current degree of secrecy around the way the EB reviews independent *> submissions. Brian, RFC 4846 (July 2007, Klensin & tHaler) established the rules for handling reviews of independent submissions. In general, the RFC Editor has been attempting to follow that document since it was published. Originally, the RFC Editor used the academic model, in which reviews are (of course) shared with the author but not made public. RFC 4846 generally favors posting of reviews, although in fact it does not absolutely require it; see section 7.1. In any case, the RFC Editor intends to follow the general thrust of 4846 by posting reviews on our web site, and we began the process of making that happen. Unfortunately, higher priority issues intervened, and we never got back to complete the task. Thanks for your comment, and we will try to remove the veil of "secrecy" ASAP. Bob Braden Especially if we end up spending IASA money explicitly *> for this stream, I'd like to see all EB reviews being made public. *> People who want to publish via confidential peer review have lots *> of other places to try. From brian.e.carpenter at gmail.com Thu Jun 5 14:24:46 2008 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 06 Jun 2008 09:24:46 +1200 Subject: [rfc-i] IPv6 support in place In-Reply-To: <200806051807.LAA06222@gra.isi.edu> References: <200806051807.LAA06222@gra.isi.edu> Message-ID: <4848599E.9010100@gmail.com> Bob, Thanks! HTTP access to www.rfc-editor.org via IPv6 works just fine. However, ftp.rfc-editor.org does *not* have a AAAA* record. rfc-editor.org does *not* have a AAAA record that I can see. Your MX record points to a mail server that does not have a AAAA record that I can see. Regards Brian Carpenter University of Auckland *Since AAAA is pronounced Quad-A, I presume it takes "a" not "an", but I don't know what the styel manual says ;-) On 2008-06-06 06:07, Bob Braden wrote: > > We believe that the RFC Editor web site is now live using IPv6 > (at last!). It has had somewhat minimal testing, so we > invite you to break it ;-). > > I am told that there are AAAA records for www.rfc-editor.org > and rfc-editor.org. > > Bob Braden for the RFC Editor > _______________________________________________ > rfc-interest mailing list > rfc-interest at rfc-editor.org > http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest > From brian.e.carpenter at gmail.com Thu Jun 5 14:33:05 2008 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 06 Jun 2008 09:33:05 +1200 Subject: [rfc-i] RFC Editor Structure In-Reply-To: <200806051838.LAA06286@gra.isi.edu> References: <200806051838.LAA06286@gra.isi.edu> Message-ID: <48485B91.90904@gmail.com> Bob, Yes, I'm aware of the history here and I'm only repeating my previous opinion on this. I have to say that over the years I've come to greatly prefer the fully open model of review, even if one does get roasted in public from time to time. The academic model of confidential review is a good way to filter out substandard work at an early stage, but public review seems to be the best way to get high-quality documents at the end of the process. I'm not sure why this community would want to do it any other way. (There's a risk of pocket veto in any model, but we have checks and balances to prevent that.) Brian On 2008-06-06 06:38, Bob Braden wrote: > > *> > *> 2. Also re the Independent Stream: "...no changes to the Editorial > *> Board are being proposed." Let's discuss that. I don't like the > *> current degree of secrecy around the way the EB reviews independent > *> submissions. > > Brian, > > RFC 4846 (July 2007, Klensin & tHaler) established the rules for > handling reviews of independent submissions. In general, the RFC > Editor has been attempting to follow that document since it was > published. > > Originally, the RFC Editor used the academic model, in which reviews > are (of course) shared with the author but not made public. RFC 4846 > generally favors posting of reviews, although in fact it does not > absolutely require it; see section 7.1. In any case, the RFC Editor > intends to follow the general thrust of 4846 by posting reviews on our > web site, and we began the process of making that happen. > Unfortunately, higher priority issues intervened, and we never got back > to complete the task. Thanks for your comment, and we will try to > remove the veil of "secrecy" ASAP. > > Bob Braden > > > Especially if we end up spending IASA money explicitly > *> for this stream, I'd like to see all EB reviews being made public. > *> People who want to publish via confidential peer review have lots > *> of other places to try. > > From sm at resistor.net Thu Jun 5 14:40:19 2008 From: sm at resistor.net (SM) Date: Thu, 05 Jun 2008 14:40:19 -0700 Subject: [rfc-i] IPv6 support in place In-Reply-To: <4848599E.9010100@gmail.com> References: <200806051807.LAA06222@gra.isi.edu> <4848599E.9010100@gmail.com> Message-ID: <6.2.5.6.2.20080605143856.0342a798@resistor.net> Hi Brian, At 14:24 05-06-2008, Brian E Carpenter wrote: >rfc-editor.org does *not* have a AAAA record that I can see. rfc-editor.org. 3600 IN AAAA 2001:1878:400:1:214:4fff:fe67:9351 Regards, -sm From brian.e.carpenter at gmail.com Thu Jun 5 15:24:53 2008 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 06 Jun 2008 10:24:53 +1200 Subject: [rfc-i] IPv6 support in place In-Reply-To: <6.2.5.6.2.20080605143856.0342a798@resistor.net> References: <200806051807.LAA06222@gra.isi.edu> <4848599E.9010100@gmail.com> <6.2.5.6.2.20080605143856.0342a798@resistor.net> Message-ID: <484867B5.4000404@gmail.com> On 2008-06-06 09:40, SM wrote: > Hi Brian, > At 14:24 05-06-2008, Brian E Carpenter wrote: >> rfc-editor.org does *not* have a AAAA record that I can see. > > rfc-editor.org. 3600 IN AAAA > 2001:1878:400:1:214:4fff:fe67:9351 > > Regards, > -sm Interesting. Yes, it's now arrived at kronos1.cs.auckland.ac.nz It wouldn't resolve an hour ago. Brian From paul.hoffman at vpnc.org Thu Jun 5 20:39:13 2008 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Thu, 5 Jun 2008 20:39:13 -0700 Subject: [rfc-i] IPv6 support in place In-Reply-To: <484867B5.4000404@gmail.com> References: <200806051807.LAA06222@gra.isi.edu> <4848599E.9010100@gmail.com> <6.2.5.6.2.20080605143856.0342a798@resistor.net> <484867B5.4000404@gmail.com> Message-ID: At 10:24 AM +1200 6/6/08, Brian E Carpenter wrote: >On 2008-06-06 09:40, SM wrote: >> Hi Brian, >> At 14:24 05-06-2008, Brian E Carpenter wrote: >>> rfc-editor.org does *not* have a AAAA record that I can see. >> >> rfc-editor.org. 3600 IN AAAA >> 2001:1878:400:1:214:4fff:fe67:9351 >> >> Regards, >> -sm > >Interesting. Yes, it's now arrived at kronos1.cs.auckland.ac.nz >It wouldn't resolve an hour ago. That's because when you try to resolve at one of rfc-editor.org's two name servers (VENERA.ISI.EDU), you get nothing. The box is pingable but does not respond to DNS queries. --Paul Hoffman, Director --VPN Consortium From braden at ISI.EDU Fri Jun 6 12:11:41 2008 From: braden at ISI.EDU (Bob Braden) Date: Fri, 6 Jun 2008 12:11:41 -0700 (PDT) Subject: [rfc-i] New queue file Message-ID: <200806061911.MAA07254@gra.isi.edu> The recently-introduced concept of RFC document streams (IETF/IAB/IRTF/independent) allows us to escape from a very ancient confusion in classifying entries in the online queue display (http://www.rfc-editor.org/queue.html). The confusion arose in the Informational/Experimental grouping... it grouped IETF and independent submissions together. We have now created a new queue display that classifies entries by stream, unambiguously. It it available at http://www.rfc-editor.org/queue2.html. We plan to eventually replace queue.html by queue2.html. We are open to suggestions on how soon we can do that without causing problems with screen-scrapers. (We accidentally installed queue2.html as queue.html, and a few hours later someone noticed, so we backed it out.) Screen-scrapers beware. RFC Editor From julian.reschke at gmx.de Fri Jun 6 12:51:16 2008 From: julian.reschke at gmx.de (Julian Reschke) Date: Fri, 06 Jun 2008 21:51:16 +0200 Subject: [rfc-i] New queue file In-Reply-To: <200806061911.MAA07254@gra.isi.edu> References: <200806061911.MAA07254@gra.isi.edu> Message-ID: <48499534.8030804@gmx.de> Bob Braden wrote: > ... > Screen-scrapers beware. > ... We've had for almost three years now. Are people *still* scraping the HTML??? BR, Julian From paul.hoffman at vpnc.org Fri Jun 6 13:39:56 2008 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Fri, 6 Jun 2008 13:39:56 -0700 Subject: [rfc-i] New queue file In-Reply-To: <48499534.8030804@gmx.de> References: <200806061911.MAA07254@gra.isi.edu> <48499534.8030804@gmx.de> Message-ID: At 9:51 PM +0200 6/6/08, Julian Reschke wrote: >Bob Braden wrote: >> ... >> Screen-scrapers beware. >> ... > > >We've had for almost three years now. > >Are people *still* scraping the HTML??? How would someone know the XML exists? It isn't listed on the queue.html page... --Paul Hoffman, Director --VPN Consortium From moore at cs.utk.edu Fri Jun 6 14:11:59 2008 From: moore at cs.utk.edu (Keith Moore) Date: Fri, 06 Jun 2008 17:11:59 -0400 Subject: [rfc-i] New queue file In-Reply-To: References: <200806061911.MAA07254@gra.isi.edu> <48499534.8030804@gmx.de> Message-ID: <4849A81F.4040709@cs.utk.edu> An HTML attachment was scrubbed... URL: http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20080606/e54aadb2/attachment.html From carl at media.org Fri Jun 6 14:15:51 2008 From: carl at media.org (Carl Malamud) Date: Fri, 6 Jun 2008 14:15:51 -0700 Subject: [rfc-i] New queue file In-Reply-To: References: <200806061911.MAA07254@gra.isi.edu> <48499534.8030804@gmx.de> Message-ID: <630BBBCC-B653-4E87-B80D-E7F015442870@media.org> On Jun 6, 2008, at 1:39 PM, Paul Hoffman wrote: >>> > How would someone know the XML exists? It isn't listed on the > queue.html page... It has been mentioned on the rfc list quite a few times: http://www.google.com/search?q=queue.xml+site:rfc-editor.org It is also a frequent item on their whatsnew page. And, if you go look at xml.resource.org, you'll see also parse the queue file and produce yet another feed of xml out of that, this one rss-based. Carl From nobody at xyzzy.claranet.de Fri Jun 6 18:15:16 2008 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Sat, 7 Jun 2008 03:15:16 +0200 Subject: [rfc-i] New queue file References: <200806061911.MAA07254@gra.isi.edu> Message-ID: Bob Braden wrote: > The confusion arose in the Informational/Experimental grouping... > it grouped IETF and independent submissions together. You could drop IETF WG vs. IETF non-WG if you want KISS, the name usually indicates draft-ietf-wg-... vs. draft-non-wg-... Just an idea. If you keep queue2.html as is I'm not sure that draft-shimaoka-multidomain-pki-13.txt belongs into an IETF WG section. > Screen-scrapers beware. They should use your XML version, that's why you've created it. Frank From fenner at fenron.com Fri Jun 6 20:42:36 2008 From: fenner at fenron.com (Bill Fenner) Date: Fri, 6 Jun 2008 23:42:36 -0400 Subject: [rfc-i] New queue file In-Reply-To: <48499534.8030804@gmx.de> References: <200806061911.MAA07254@gra.isi.edu> <48499534.8030804@gmx.de> Message-ID: On Jun 6, 2008, at 3:51 PM, Julian Reschke wrote: > Bob Braden wrote: >> ... >> Screen-scrapers beware. >> ... > > > We've had for almost three > years now. > > Are people *still* scraping the HTML??? My screen scraper has worked fine for the last 6 years - since it hasn't broken I haven't fixed it. I will switch to XML *now*... :-) Bill From hagens at ISI.EDU Mon Jun 9 09:38:41 2008 From: hagens at ISI.EDU (Alice Hagens) Date: Mon, 9 Jun 2008 09:38:41 -0700 Subject: [rfc-i] New queue file In-Reply-To: References: <200806061911.MAA07254@gra.isi.edu> Message-ID: Frank, Thank you for bringing draft-shimaoka-multidomain-pki-13 to our attention. Its source information has been corrected in the database, so now both queue.html and queue2.html list it as non-WG. RFC Editor/ah On Jun 6, 2008, at 6:15 PM, Frank Ellermann wrote: > Bob Braden wrote: > >> The confusion arose in the Informational/Experimental grouping... >> it grouped IETF and independent submissions together. > > You could drop IETF WG vs. IETF non-WG if you want KISS, the > name usually indicates draft-ietf-wg-... vs. draft-non-wg-... > > Just an idea. If you keep queue2.html as is I'm not sure that > draft-shimaoka-multidomain-pki-13.txt belongs into an IETF WG > section. > >> Screen-scrapers beware. > > They should use your XML version, that's why you've created it. > > Frank > > _______________________________________________ > rfc-interest mailing list > rfc-interest at rfc-editor.org > http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest From bortzmeyer at nic.fr Tue Jun 10 01:29:50 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 10 Jun 2008 10:29:50 +0200 Subject: [rfc-i] New queue file In-Reply-To: References: <200806061911.MAA07254@gra.isi.edu> <48499534.8030804@gmx.de> Message-ID: <20080610082950.GA3527@nic.fr> On Fri, Jun 06, 2008 at 01:39:56PM -0700, Paul Hoffman wrote a message of 20 lines which said: > How would someone know the XML exists? It isn't listed on the > queue.html page... I believe it is officially experimental only. And, indeed, it was often broken. (I hope it works now.) From julian.reschke at gmx.de Tue Jun 10 01:36:52 2008 From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 10 Jun 2008 10:36:52 +0200 Subject: [rfc-i] New queue file In-Reply-To: <20080610082950.GA3527@nic.fr> References: <200806061911.MAA07254@gra.isi.edu> <48499534.8030804@gmx.de> <20080610082950.GA3527@nic.fr> Message-ID: <484E3D24.8030705@gmx.de> Stephane Bortzmeyer wrote: > On Fri, Jun 06, 2008 at 01:39:56PM -0700, > Paul Hoffman wrote > a message of 20 lines which said: > >> How would someone know the XML exists? It isn't listed on the >> queue.html page... > > I believe it is officially experimental only. And, indeed, it was > often broken. (I hope it works now.) I routinely use it. It was broken several times (as bugs in the generation process were discovered), but then it was fixed each time quickly. BR, Julian From bortzmeyer at nic.fr Tue Jun 10 02:00:49 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 10 Jun 2008 11:00:49 +0200 Subject: [rfc-i] New queue file In-Reply-To: <484E3D24.8030705@gmx.de> References: <200806061911.MAA07254@gra.isi.edu> <48499534.8030804@gmx.de> <20080610082950.GA3527@nic.fr> <484E3D24.8030705@gmx.de> Message-ID: <20080610090049.GA10380@nic.fr> On Tue, Jun 10, 2008 at 10:36:52AM +0200, Julian Reschke wrote a message of 17 lines which said: > It was broken several times (as bugs in the generation process were > discovered), but then it was fixed each time quickly. And reappeared as quickly. The file was fixed, not the generation process. I hope it works now (the last bug I've seen was only one month ago: rfc-editor-queue.xml:1114: validity error : xml:id : attribute value is not an NCName ^ From julian.reschke at gmx.de Tue Jun 10 02:35:46 2008 From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 10 Jun 2008 11:35:46 +0200 Subject: [rfc-i] New queue file In-Reply-To: <20080610090049.GA10380@nic.fr> References: <200806061911.MAA07254@gra.isi.edu> <48499534.8030804@gmx.de> <20080610082950.GA3527@nic.fr> <484E3D24.8030705@gmx.de> <20080610090049.GA10380@nic.fr> Message-ID: <484E4AF2.1000107@gmx.de> Stephane Bortzmeyer wrote: > On Tue, Jun 10, 2008 at 10:36:52AM +0200, > Julian Reschke wrote > a message of 17 lines which said: > >> It was broken several times (as bugs in the generation process were >> discovered), but then it was fixed each time quickly. > > And reappeared as quickly. The file was fixed, not the generation > process. I hope it works now (the last bug I've seen was only one > month ago: > > rfc-editor-queue.xml:1114: validity error : xml:id : attribute value is not an NCName > Ah, validity :-) My code wasn't checking it, but I will add that. BR, Julian From braden at ISI.EDU Tue Jun 10 09:07:09 2008 From: braden at ISI.EDU (Bob Braden) Date: Tue, 10 Jun 2008 09:07:09 -0700 (PDT) Subject: [rfc-i] New queue file Message-ID: <200806101607.JAA08382@gra.isi.edu> *> *> And reappeared as quickly. The file was fixed, not the generation *> process. I hope it works now (the last bug I've seen was only one Since the file is generated daily under cron, fixing the file is equivalent to fixing the generation process. Bob Braden From braden at ISI.EDU Tue Jun 10 09:33:37 2008 From: braden at ISI.EDU (Bob Braden) Date: Tue, 10 Jun 2008 09:33:37 -0700 (PDT) Subject: [rfc-i] New queue file Message-ID: <200806101633.JAA08423@gra.isi.edu> *> *> How would someone know the XML exists? It isn't listed on the *> queue.html page... *> *> --Paul Hoffman, Director *> --VPN Consortium *> Sheesh! The next thing, you will be asking for a *schema* for queue.xml. Bob Braden From bortzmeyer at nic.fr Wed Jun 11 01:35:18 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 11 Jun 2008 10:35:18 +0200 Subject: [rfc-i] New queue file In-Reply-To: <200806101633.JAA08423@gra.isi.edu> References: <200806101633.JAA08423@gra.isi.edu> Message-ID: <20080611083518.GA20236@nic.fr> On Tue, Jun 10, 2008 at 09:33:37AM -0700, Bob Braden wrote a message of 17 lines which said: > The next thing, you will be asking for a *schema* for queue.xml. That would be a good idea. http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1138083 From paul.hoffman at vpnc.org Thu Jun 12 09:24:04 2008 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Thu, 12 Jun 2008 09:24:04 -0700 Subject: [rfc-i] Fwd: Re: RFC 5274 on Certificate Managmement Messages over CMS (CMC): Complience Requirements Message-ID: Forwarded from the PKIX WG mailing list. >X-Authentication-Warning: balder-227.proper.com: majordom set sender >to owner-ietf-pkix at mail.imc.org using -f >From: Yoav Nir >To: ietf-pkix at imc.org >Subject: Re: RFC 5274 on Certificate Managmement Messages over CMS >(CMC): Complience Requirements >Date: Thu, 12 Jun 2008 08:17:14 +0300 >X-Mailer: Apple Mail (2.924) >Sender: owner-ietf-pkix at mail.imc.org >List-Archive: >List-ID: >List-Unsubscribe: > > >Well, at least the real RFC doesn't have the spelling mistakes. >s/Managmement/Management/ >s/Complience/Compliance/ > >On Jun 12, 2008, at 2:43 AM, rfc-editor at rfc-editor.org wrote: > >> >> >>A new Request for Comments is now available in online RFC libraries. >> >> >> RFC 5274 >> >> Title: Certificate Managmement Messages over CMS >> (CMC): Complience Requirements >> Author: J. Schaad, M. Myers >> Status: Standards Track >> Date: June 2008 >> Mailbox: jimsch at nwlink.com, mmyers at fastq.com >> Pages: 13 >> Characters: 27380 >> Updates/Obsoletes/SeeAlso: None >> >> I-D Tag: draft-ietf-pkix-cmc-compl-05.txt >> >> URL: http://www.rfc-editor.org/rfc/rfc5274.txt >> >>This document provides a set of compliance statements about the CMC >>(Certificate Management over CMS) enrollment protocol. The ASN.1 >>structures and the transport mechanisms for the CMC enrollment >>protocol are covered in other documents. This document provides the >>information needed to make a compliant version of CMC. [STANDARDS TRACK] >> >>This document is a product of the Public-Key Infrastructure (X.509) >>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 >> >> >> >>Scanned by Check Point Total Security Gateway. From nobody at xyzzy.claranet.de Sun Jun 15 19:40:38 2008 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Mon, 16 Jun 2008 04:40:38 +0200 Subject: [rfc-i] Errata report system nit Message-ID: Hi, for RFC 3092 the errata report system picked the IESG as responsible party, I think it should be the RFC editor for April 1st RFCs such as RFC 3092. Frank From brian.e.carpenter at gmail.com Sun Jun 15 19:48:17 2008 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Mon, 16 Jun 2008 14:48:17 +1200 Subject: [rfc-i] New queue file In-Reply-To: <200806061911.MAA07254@gra.isi.edu> References: <200806061911.MAA07254@gra.isi.edu> Message-ID: <4855D471.4060103@gmail.com> Hi, On 2008-06-07 07:11, Bob Braden wrote: > The recently-introduced concept of RFC document streams > (IETF/IAB/IRTF/independent) allows us to escape from a very ancient > confusion in classifying entries in the online queue display > (http://www.rfc-editor.org/queue.html). The confusion arose in the > Informational/Experimental grouping... it grouped IETF and independent > submissions together. > > We have now created a new queue display that classifies entries by > stream, unambiguously. It it available at > http://www.rfc-editor.org/queue2.html. We plan to eventually replace > queue.html by queue2.html. I think this separation is an excellent step forward. Thanks. (I'd also like to see it, and in fact all the streams identified in RFC 4844, reflected in "Status of This Memo".) I can't help wondering whether the community should be notified of impending publications for all the streams, too. Maybe there could be an indep-announce mailing list, where a message would be generated when an independent submission enters the RFC3932 process? Brian From rfc-editor at rfc-editor.org Mon Jun 16 09:52:59 2008 From: rfc-editor at rfc-editor.org (RFC Editor) Date: Mon, 16 Jun 2008 09:52:59 -0700 Subject: [rfc-i] Errata report system nit In-Reply-To: References: Message-ID: <20080616165259.GA5903@isi.edu> Hi Frank, Thank you for bringing this error to our attention. You are correct, the RFC Editor is the responsible verifying party for this document. We have updated our database. Thank you! Sandy On Mon, Jun 16, 2008 at 04:40:38AM +0200, Frank Ellermann wrote: > Hi, for RFC 3092 the errata report system picked the IESG > as responsible party, I think it should be the RFC editor > for April 1st RFCs such as RFC 3092. > > Frank > > _______________________________________________ > rfc-interest mailing list > rfc-interest at rfc-editor.org > http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest From nobody at xyzzy.claranet.de Thu Jun 19 21:59:41 2008 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Fri, 20 Jun 2008 06:59:41 +0200 Subject: [rfc-i] Updated erratum (was: Errata report system nit) References: <20080616165259.GA5903@isi.edu> Message-ID: Sandy wrote: > We have updated our database. Thanks. I just stumbled over another nit, the errata report system does not yet handle new errata updating older errata. IOW I did not get a copy of Errata-ID: 1533 updating 1081, and was not aware of its existence. AFAIK "bugzilla" would have all features you need. And various features you don't need, I certainly hate its user interface, but it's an idea. For now I try "reply all" to the 1081 Cc: list adding John. Frank From nobody at xyzzy.claranet.de Thu Jun 19 22:29:26 2008 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Fri, 20 Jun 2008 07:29:26 +0200 Subject: [rfc-i] Updated erratum References: <20080616165259.GA5903@isi.edu> Message-ID: > For now I try "reply all" to the 1081 Cc: list adding John. "Try" :-( I managed to confuse 1081 and 1353 in the summary: | Errata ID: 1081 (2007-11) was updated by Errata ID: 1353 (2008-03). | The fix proposed in ID 1353 is clearly better, e.g., ID 1081 allowed | (in theory) a toplabel 1-2-3, but ID 1353 requires a leading letter. | - If ID 1081 is verified this should trigger follow-up errata for RFCs + If ID 1353 is verified this should trigger follow-up errata for RFCs | 3696, 4408, and ietf-usefor-usefor. This list might be incomplete. Frank From paul.hoffman at vpnc.org Sun Jun 22 07:49:05 2008 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Sun, 22 Jun 2008 07:49:05 -0700 Subject: [rfc-i] RFC Editor Structure In-Reply-To: <48485B91.90904@gmail.com> References: <200806051838.LAA06286@gra.isi.edu> <48485B91.90904@gmail.com> Message-ID: The proposed RFC Editor structure looks fine. It's good to see the IAB getting this straightened out so that future bidders on the RFC Editor contracts can know what they are bidding on. As many people know, Standcore (basically, John Levine and I) bid on the RFC Editor RFP last year, so we have thought a great deal about what kind of structure would make sense. We think the proposed four-part model makes sense. A few notes on the specifics: - Of the two proposals for selecting the RFC Editor role (RFP from the IAOC, selected by the community), having the RFC Editor being chosen by an RFP from the IAOC is probably best. It seems likely that bidders would want to bid on the RFC Editor and Production House tasks at the same time, and it would make sense to let the IAOC bid the two of them simultaneously. - The person in the ISS role preferably should *not* work in the same organization as the RFC Production House role. Having the Independent Stream queue being input to the same organization that is supposed be managing the queue can lead to errors and misunderstandings. All four queues should be on the same footing. - The RFC Publisher is truly a minor amount of work. If it is not just given to the Secretariat, it should probably be part of the RFC Production House job and let as a variable price contract. It is hard to see how this would cost more than $3000/year, and could easily be less than that, meaning that it is less than 1% of the RFC Editor budget. - The structure document did not lay out who would be responsible for creating the new tools that many people have asked for, that would make the process faster and more understandable. These include modern tracking of author reviews, an updated xml2rfc system, better search facilities, and integration of the RFC Editor queue and the I-D Tracker. These tools could be developed by the RFC Production House or the RFC Editor, but should be done with oversight of the IAOC and with a specific budget for the tools. Again, we feel that the structure proposed is a good one, and we look forward to helping with the evolution of this important task. --Paul Hoffman --Paul Hoffman, Director --VPN Consortium From brian.e.carpenter at gmail.com Sun Jun 22 13:53:20 2008 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Mon, 23 Jun 2008 08:53:20 +1200 Subject: [rfc-i] RFC Editor Structure In-Reply-To: References: <200806051838.LAA06286@gra.isi.edu> <48485B91.90904@gmail.com> Message-ID: <485EBBC0.6050200@gmail.com> Paul, On 2008-06-23 02:49, Paul Hoffman wrote: ... > - Of the two proposals for selecting the RFC Editor role (RFP from > the IAOC, selected by the community), having the RFC Editor being > chosen by an RFP from the IAOC is probably best. It seems likely that > bidders would want to bid on the RFC Editor and Production House > tasks at the same time, and it would make sense to let the IAOC bid > the two of them simultaneously. What do you see as the advantage in separating these two functions into two bids? Wouldn't it be very clumsy for them to be executed separately? Brian From paul.hoffman at vpnc.org Mon Jun 23 08:07:31 2008 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Mon, 23 Jun 2008 08:07:31 -0700 Subject: [rfc-i] RFC Editor Structure In-Reply-To: <485EBBC0.6050200@gmail.com> References: <200806051838.LAA06286@gra.isi.edu> <48485B91.90904@gmail.com> <485EBBC0.6050200@gmail.com> Message-ID: At 8:53 AM +1200 6/23/08, Brian E Carpenter wrote: >Paul, > >On 2008-06-23 02:49, Paul Hoffman wrote: >... >> - Of the two proposals for selecting the RFC Editor role (RFP from >> the IAOC, selected by the community), having the RFC Editor being >> chosen by an RFP from the IAOC is probably best. It seems likely that >> bidders would want to bid on the RFC Editor and Production House >> tasks at the same time, and it would make sense to let the IAOC bid >> the two of them simultaneously. > >What do you see as the advantage in separating these two functions >into two bids? Wouldn't it be very clumsy for them to be executed >separately? Actually, we don't see any advantage in separating them; my apologies if I made it sound like we did. We assumed that if the IAB wanted the two roles separated, they had a good reason to do so. We don't think it would necessarily be "clumsy" to have two different people in the roles, but it would add overhead that isn't necessary. If both roles are done by the same person, that's fine too. --Paul Hoffman, Director --VPN Consortium From Olaf at NLnetLabs.nl Tue Jun 24 07:21:29 2008 From: Olaf at NLnetLabs.nl (Olaf Kolkman) Date: Tue, 24 Jun 2008 16:21:29 +0200 Subject: [rfc-i] RFC Editor Structure In-Reply-To: <8456FB73-2EAF-4AB3-B1FD-43D5379B4D8E@nlnetlabs.nl> References: <8456FB73-2EAF-4AB3-B1FD-43D5379B4D8E@nlnetlabs.nl> Message-ID: <3C8A4E78-1E69-4D8E-9B99-7A40D4AEAF8F@nlnetlabs.nl> [Dropping the independent list in order to keep the discussion constrained to one place] What follows are some clarifications and answers to issues brought up during the discussion. On Jun 4, 2008, at 3:59 PM, Frank Ellermann wrote: > Olaf Kolkman wrote: > >> The proposed model is posted on the RFC interest list, see >> http://mailman.rfc-editor.org/pipermail/rfc-interest/2008-May/000581.html >> and made available through >> http://www.iab.org/documents/resources/RFC-Editor-Model.html > > Thanks for info. Some quick observations while looking at the > picture of your model: You don't cover the rather convoluted > interactions between IESG and "ISS", to fix that please sort > the "stream" columns like that: IAB | IETF | community | IRTF. > Yes, the picture does take a high level view of the processes and production process. But to clarify: The convoluted interactions are documented in RFC4846, with cross reference to 3932, and thus well defined part of the existing review process. Nothing here that is going to change that. It is the ISS that in this model is responsible for following the process. Once the ISS is done a document with appropriate boilerplates pops out and the RFC production house takes over. Frank also asked: > > What does "selected by the community and confirmed by the IAB" > actually mean, is it the same idea as for area directors, i.e. > NomCom representing a random set of volunteers from visitors of > three out of five recent IETF meetings ? That is one of the approaches, in the document we suggested an approach similar to that of RFC4333. There may be other approaches to selection of the ISS and the RFC Editor, and those selection processes may be different. Ideas, suggestions, and opinions are most welcome Frank again: > Why should there be two persons - new "ISS" and new RFC-editor - > instead of one ? In what way would a new "ISS" selected by the > NomCom be really independent from IETF / IESG considerations, > which is the whole point of this "independent" escape hatch as > noted two years ago in the RFC 4844 discussions by John Klensin ? The _intention_ is to recognize the independence of the stream and construct an appointment process that matches that. This intention is (attempted to be) captured in the profile of the ISS "Good standing in the technical community in and beyond the IETF". The reason why there are two _functions_ in the model is because they are different in nature and responsibilities. The ISS being an experienced technical person that understands the content and organizes and manages the process for getting that content reviewed and takes responsibility for approval. The RFC Editor being with a focus on style, presentation, and series continuity. It seemed natural to decouple to function description. But it is not said that the same person, or organization cannot fill both of these functions. In fact, observe that Brian Carpenter suggested coupling between the Editor and the Production function. Frank continued: > > RFC number assignment should be the privilege of the RFC editor, > not of some "outsourced" RFC production entity. This used to be > great magic in the past, and it is a completely subjective magic. > In an earlier version the RFC assignment lived with the editor. It was thought to be more pragmatic to move the magic to the production house, this seemed to be more in line with the current practice, as Bob Braden also argued in his June 4 reply. And finally Frank remarked: > > Moving some "RFC publisher" functions to the IETF secretariat > could make sense, if that is about maintaining a high traffic > Web server with tricky forms. But the quality of some IETF Web > server forms is not yet up to the standard of some RFC editor > forms. Working Web forms can't be expensive, please don't try > to fix it if it is not broken. That is to some extend an implementation issue that should be decoupled from the long term perspective that we are trying to make with documenting this model. Brian also had a number of queries: > 1. What's the funding model for the "Independent Stream Supervisor"? > That's not a job title that is very inspiring, and if it's a volunteer > position, it would seem very unlikely to me that we'll find reliable > and conscientious individuals willing to do it in the long term. > I don't see it as comparable to an unpaid Editorship of an academic > journal, for example, unless it is described in much more exciting > language. But it also seems hard to justify as a funded service > on its own. "Expenses to support the administrative operation of > the Independent Stream Supervisor selected in this manner would > be part of the IASA budget." Well, that is a very explicit extension > of the scope of IASA beyond IETF activities. I'd want to see a > consensus call on that. Currently the funding is provided through the RFC-Editor contract that is in place with ISI, so de-facto this is already covered by the IASA budget. In fact all functions in the model are currently executed and funded by IASA. Calling out the ISS as a separate function allows us to think about separate funding sources, although that also opens the question about the selection process. Brian also remarked: > 2. Also re the Independent Stream: "...no changes to the Editorial > Board are being proposed." Let's discuss that. I don't like the > current degree of secrecy around the way the EB reviews independent > submissions. Especially if we end up spending IASA money explicitly > for this stream, I'd like to see all EB reviews being made public. > People who want to publish via confidential peer review have lots > of other places to try. Although maybe not completely orthogonal I think it would be good to have that discussion separate from this particular discussion. We converged on the independent approval process about 1-2 years ago and that cumulated in RFC 4846. What is important though is to assess if this model would prevent any changes to the approval process. I do not think it does. Finally I observe that we have had no concrete feedback on the selection process by which the ISS and the RFC Editor should be selected. Would folk consent with a RFC 4333 type selection of those roles? --Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20080624/2b4aba4d/attachment.html -------------- 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/20080624/2b4aba4d/PGP.bin From paul.hoffman at vpnc.org Tue Jun 24 14:54:00 2008 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Tue, 24 Jun 2008 14:54:00 -0700 Subject: [rfc-i] Selection process for the ISS and RFC Editor roles In-Reply-To: <3C8A4E78-1E69-4D8E-9B99-7A40D4AEAF8F@nlnetlabs.nl> References: <8456FB73-2EAF-4AB3-B1FD-43D5379B4D8E@nlnetlabs.nl> <3C8A4E78-1E69-4D8E-9B99-7A40D4AEAF8F@nlnetlabs.nl> Message-ID: At 4:21 PM +0200 6/24/08, Olaf Kolkman wrote: >Finally I observe that we have had no concrete feedback on the >selection process by which the ISS and the RFC Editor should be >selected. Would folk consent with a RFC 4333 type selection of those >roles? A RFC 4333-style selection process is probably OK for the ISS role (review independent submissions) and the RFC Editor role (RFC series continuity, style manual, and errata processing). However, from earlier parts of this discussion, it sounds like both roles are meant to be paid positions. If so, using RFC 4333-style selection to select the people to fill the roles might be a bit odd, since RFC 4333 was designed to select volunteers. The compensation for each role would need to be stated up front without negotiating with the chosen candidate; otherwise, the people putting their names up for consideration won't know whether or not they would want to accept if chosen. While predicting the number of hours it might take to perform the ISS role based on history is possible, doing so for the new RFC Editor role is probably impossible due to lack of data. (As an aside, it would be nice if ISS were compensated by ISOC instead of IASA to make the independence clearer.) One possibility is that the IAB and IASA agree ahead of time what the compensation for the ISS role would be, then do an RFC 4333-style selection process, while having the RFC Editor role chosen by an IASA-led bidding process like it was a few years ago. --Paul Hoffman, Director --VPN Consortium