From falk at ISI.EDU Tue Jun 1 15:12:13 2004 From: falk at ISI.EDU (Aaron Falk) Date: Tue Jun 1 15:13:08 2004 Subject: [rfc-i] RFC (and ID) announcements via RSS Message-ID: Folks- Sean Burke put together a very nifty RSS feed of RFC and ID announcements. Forwarding with his encouragement... --aaron Begin forwarded message: > > > On May 28, 2004, at 6:31 PM, Sean M. Burke wrote: > >> At 01:54 PM 2004-05-28, you wrote: >>> Seems to be fixed. Can you send the info on the RSS feed? I know >>> you asked about us supporting it last year and am glad you put it >>> together on your own. I'd like to see what you've come up with.... >> >> OK, here's some relevent URLs: >> >> The Perl program that generates the feed: >> http://interglacial.com/rss/rfc/new_rfc_list_gen.pl >> The feed: >> http://interglacial.com/rss/rfc/new_rfcs.rss >> And the stylesheet it uses: >> http://interglacial.com/rss/rfc/rss.css >> That's it for mere RFCs. >> >> >> Meanwhile, more elaborate stuff is generated for IDs. >> The generator: >> http://interglacial.com/rss/internet-drafts/new_ids.pl >> See all the group-specific RSSs that it generates: >> http://interglacial.com/rss/internet-drafts/ >> A more machine-readable format of that list: >> >> http://interglacial.com/rss/internet-drafts/ >> internet_drafts___groups.dat >> >> >> An RSS of new RSSs in there (i.e., an RSS of new groups): >> >> http://interglacial.com/rss/internet-drafts/ >> internet_drafts___groups.rss >> >> An RSS of new ID documents across all groups: >> http://interglacial.com/rss/internet-drafts/internet-draft-__all.rss >> >> And the stylesheet that those RSSs use: >> http://interglacial.com/rss/rss.css >> >> >> I used to be very eager to get these hosted elsewhere, because I >> thought it would be responsible for a lot of server traffic. But >> that hasn't been the case, so I basically don't have to worry about >> it at all. Each of my other feeds (http://interglacial.com/rss/) >> gets a LOT more traffic than even all these RFC + ID things combined. >> So I'm perfectly happy having this all on my server. Feel free to >> link to it merrily and widely! The more the merrier the faster the >> easier. >> >> -- >> Sean M. Burke http://search.cpan.org/~sburke/ From paul.hoffman at vpnc.org Thu Jun 10 08:56:08 2004 From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC) Date: Thu Jun 10 08:56:46 2004 Subject: [rfc-i] Five-author maximum? Message-ID: Greetings again. New in the pre-publication queue is: Network Working Group P. Karn, Ed. Request for Comments: 3819 Qualcomm BCP: 89 C. Bormann Category: Best Current Practice Universitaet Bremen FB3 TZI G. Fairhurst University of Aberdeen D. Grossman Motorola, Inc. R. Ludwig Ericsson Research J. Mahdavi Novell G. Montenegro Sun Microsystems Laboratories, Europe J. Touch USC/ISI L. Wood Cisco Systems June 2004 Advice for Internet Subnetwork Designers This seems to bust the five-authors suggestion by a significant number. Are each of these people really responsible for all of the content? Given Phil's designation as "Ed." on the top line, it seems likely that the author-name-padding should be removed. --Paul Hoffman, Director --VPN Consortium From mallman at icir.org Thu Jun 10 09:32:17 2004 From: mallman at icir.org (Mark Allman) Date: Thu Jun 10 09:32:46 2004 Subject: [rfc-i] Five-author maximum? In-Reply-To: Message-ID: <20040610163217.A9D5577AA17@guns.icir.org> Paul- > This seems to bust the five-authors suggestion by a significant > number. Are each of these people really responsible for all of the > content? Given Phil's designation as "Ed." on the top line, it seems > likely that the author-name-padding should be removed. Let me take a swing at this. I editted this document, as well. I took over from Phil for the final push. I was offered a spot on the author list and turned it down. This document was started before the 5-author limit was imposed. The folks (and more) on the current author list were all listed because they contributed lots of text and expertise. This is a big document and no one person had the required set of expertise to author it alone. When the 5-author limit was imposed the list was scaled back to just Phil. However, when we were preparing the last version of the document that felt all wrong. The people on the current author list had contributed substantially. And, it wasn't clear that we could pick 4 (besides Phil) who clearly contributed more than folks who would then have to be left off. In the 5-author policy there is a bit of wiggle room and an appeal was sent to Harald (and the IESG maybe) who seemed fine with wiggling in this particular case -- i.e., it wasn't an oversight, it was an explicit decision. That's the story. We might reasonably disagree whether it should be Phil or Phil+everyone else, or about the general policy, or whatever. **However**, I completely **reject** the notion that this document is "padded" with authors. If one were to look at the record from the PILC WG, I think one would see that all these folks made a substanative contribution. Further, this was an explicit decision not an oversight. Sorry for being a bit sensative here, but simply counting authors and suggesting author padding without attempting to understand the context and the process that was used to arrive at the author list slights these folk's work, IMO. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20040610/74c6f8a8/attachment.bin From paul.hoffman at vpnc.org Thu Jun 10 09:47:23 2004 From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC) Date: Thu Jun 10 09:47:47 2004 Subject: [rfc-i] Five-author maximum? In-Reply-To: <20040610163217.A9D5577AA17@guns.icir.org> References: <20040610163217.A9D5577AA17@guns.icir.org> Message-ID: At 12:32 PM -0400 6/10/04, Mark Allman wrote: >i.e., it wasn't an oversight, it was an explicit >decision. That's the story. Sounds good to me. It's hard to know that from looking at the document, of course. >We might reasonably disagree whether it should be Phil or Phil+everyone >else, or about the general policy, or whatever. **However**, I >completely **reject** the notion that this document is "padded" with >authors. If one were to look at the record from the PILC WG, I think >one would see that all these folks made a substanative contribution. >Further, this was an explicit decision not an oversight. Sorry for >being a bit sensative here, but simply counting authors and suggesting >author padding without attempting to understand the context and the >process that was used to arrive at the author list slights these folk's >work, IMO. My point about padding was in the Phil or Phil+everyone debate, not whether those people did much work. In many IETF documents, more than 5 people contribute a great deal of thought and text. --Paul Hoffman, Director --VPN Consortium From dmm at 1-4-5.net Thu Jun 10 09:53:42 2004 From: dmm at 1-4-5.net (David Meyer) Date: Thu Jun 10 09:54:49 2004 Subject: [rfc-i] Five-author maximum? In-Reply-To: References: <20040610163217.A9D5577AA17@guns.icir.org> Message-ID: <20040610165342.GA20015@1-4-5.net> On Thu, Jun 10, 2004 at 09:47:23AM -0700, Paul Hoffman / VPNC wrote: >> At 12:32 PM -0400 6/10/04, Mark Allman wrote: >> >i.e., it wasn't an oversight, it was an explicit >> >decision. That's the story. >> >> Sounds good to me. It's hard to know that from looking at the >> document, of course. >> >> >We might reasonably disagree whether it should be Phil or Phil+everyone >> >else, or about the general policy, or whatever. **However**, I >> >completely **reject** the notion that this document is "padded" with >> >authors. If one were to look at the record from the PILC WG, I think >> >one would see that all these folks made a substanative contribution. >> >Further, this was an explicit decision not an oversight. Sorry for >> >being a bit sensative here, but simply counting authors and suggesting >> >author padding without attempting to understand the context and the >> >process that was used to arrive at the author list slights these folk's >> >work, IMO. >> >> My point about padding was in the Phil or Phil+everyone debate, not >> whether those people did much work. In many IETF documents, more than >> 5 people contribute a great deal of thought and text. Definitely true. One thing we should likely keep in mind here is that the point of this rule (AFAIK) is to help out the RFC Editor (and hence streamline our process). There are many ways to give credit in those cases where there is an editor (like a Contributors section, distinct from the Acknowledgments section). In any event, that is what I have done on several occasions, and it seems to work pretty well. Dave From falk at ISI.EDU Thu Jun 10 10:27:07 2004 From: falk at ISI.EDU (Aaron Falk) Date: Thu Jun 10 10:28:49 2004 Subject: [rfc-i] Five-author maximum? In-Reply-To: References: Message-ID: <65D850F1-BB03-11D8-B776-000A95DBDB84@isi.edu> On Jun 10, 2004, at 8:56 AM, Paul Hoffman / VPNC wrote: > This seems to bust the five-authors suggestion by a significant > number. Are each of these people really responsible for all of the > content? Given Phil's designation as "Ed." on the top line, it seems > likely that the author-name-padding should be removed. > Paul- A reasonable question. Hopefully, the email below will answer your concerns. It was sent by a co-chair of the working group which produced the document (me) and sent to the responsible AD (Allison) and the IESG Chair (Harald). Begin forwarded message: > From: Aaron Falk > Date: November 3, 2003 2:30:59 PM PST > To: Allison Mankin , Harald Tveit Alvestrand > > Subject: authors for draft-ietf-pilc-link-design > > Allison, Harald- > > Because of my role in RFC Editor, I felt it would be useful to make > draft-ietf-pilc-link-design an early test case in limiting authors. > Some time ago, while the document was in final working group editing, > we reduced the author count from twelve: > > Phil Karn, Carsten Bormann, Gorry Fairhurst, Aaron Falk, Dan > Grossman, Reiner Ludwig, Jamshid Mahdavi, Saverio Mascolo, > Marie-Jose Montpetit, Gabriel Montenegro, Joe Touch, Lloyd Wood > > to one (plus the wg): > > Phil Karn, editor > Performance Implications of Link Characteristics Working Group > > with a detailed contributors section immediately following the > abstract. > > However, as time has passed the unfairness of this approach has > started to grate on me and I feel that it was, basically, the Wrong > Thing to do. What I'd like to do is put the most significant > contributors, who number eight: > > Phil Karn, Carsten Bormann, Gorry Fairhurst, Dan Grossman, Reiner > Ludwig, Jamshid Mahdavi, Joe Touch, Lloyd Wood > > on the cover page. > > Reading the policy carfully > (http://www.rfc-editor.org/policy.html#policy.authlist), there is no > hard limit at five authors. The policy states that the exceptions to > the guidelines may be granted "by specific IESG request." So, I'd > like to ask that you request an exception with the following > justification: > > The document "Advice to Subnet Designers" is a compendium on variety > of topics relating (mostly) transport performance to link design > parameters. The proposed authors each contributed deep expertise > without which the document would have been incomplete. While this > document represents the consensus of the PILC working group, the > listed contibutors each share significant responsibility (& credit & > blame) for creating the document. Listing only one name gives undue > credit to the sole person listed. Listing a subset of the group is > unfair because each one made a significant contribution to the end > product. For this reason, I would like to request that IESG solicit > an exemption to the five author policy of the RFC Editor. I believe > they and the community will benefit from the clear association of > this list of authors with the content. > > I should note that none of the authors has requested that I do this. > There was some grumbling when we went from twelve to one but that was > some time ago. I am making this request only because my conscience is > bugging me. > > I am quite conscious of the potential appearance of a conflict of > interest in this situation. However, because the request for > exception must come from the IESG, rather than me, I don't believe my > role as part of the RFC Editor should play a role in making this > decision. > > Thanks, > > --aaron > In response to this request, Allison suggested that I add some text which was meant to head off any concerns of author padding. The resulting "Contributors" section describes some of the specific contributions of each listed author, as well as some we chose not to list as authors (including myself and Mark Allman): > Contributors > > This document represents a consensus of the members of the IETF > Performance Implications of Link Characteristics (PILC) working > group. > > This document would not have been possible without the contributions > of a great number of people in the Performance Implications of Link > Characteristics Working Group. In particular, the following people > provided major contributions of text, editing and advice to this > document: Mark Allman provided the final editing to complete this > document. Carsten Bormann provided text on robust header > compression. Gorry Fairhurst provided text on broadcast and > multicast issues and many valuable comments on the entire document. > Aaron Falk provided text on bandwidth on demand. Dan Grossman > provided text on security considerations as well as on many facets > of > the document. Reiner Ludwig provided thorough document review and > text on TCP vs. Link-Layer Retransmission. Jamshid Mahdavi provided > text on TCP performance calculations. Saverio Mascolo provided > feedback on the document. Gabriel Montenegro provided feedback on > the document. Marie-Jose Montpetit provided text on bandwidth on > demand. Joe Touch provided text on multicast and broadcast. and > Lloyd Wood provided many valuable comments on drafts of the > document. I hope this addresses your concern. Regards, --aaron From paul.hoffman at vpnc.org Thu Jun 10 11:00:47 2004 From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC) Date: Thu Jun 10 11:01:47 2004 Subject: [rfc-i] Status of draft-rfc-editor-rfc2223bis? Message-ID: Greetings again. According to the Internet Drafts tracker, draft-rfc-editor-rfc2223bis has been stuck for nine months waiting for comments back to the shepherding AD (Harald Alvestrand). Is that really true? We reall need this document finished and made an RFC. If it isn't true, someone should get the I-D tracker to reflect reality. --Paul Hoffman, Director --VPN Consortium From dmm at 1-4-5.net Thu Jun 10 11:09:18 2004 From: dmm at 1-4-5.net (David Meyer) Date: Thu Jun 10 11:09:59 2004 Subject: [rfc-i] Status of draft-rfc-editor-rfc2223bis? In-Reply-To: References: Message-ID: <20040610180918.GA21898@1-4-5.net> On Thu, Jun 10, 2004 at 11:00:47AM -0700, Paul Hoffman / VPNC wrote: >> Greetings again. According to the Internet Drafts tracker, >> draft-rfc-editor-rfc2223bis has been stuck for nine months waiting >> for comments back to the shepherding AD (Harald Alvestrand). Is that >> really true? We reall need this document finished and made an RFC. If >> it isn't true, someone should get the I-D tracker to reflect reality. >> >> Let me suggest that it can get worse. What happens when a document goes into "Expert Review :: External Party", and an expert registers comments (that get into the COMMENTS field), then never responds to the author's response to the comments? This is one way to effectively block a document (this is very much like filibuster, only by silence). Dave From narten at us.ibm.com Thu Jun 10 11:33:24 2004 From: narten at us.ibm.com (Thomas Narten) Date: Thu Jun 10 11:33:45 2004 Subject: [rfc-i] Status of draft-rfc-editor-rfc2223bis? In-Reply-To: Message from dmm@1-4-5.net of "Thu, 10 Jun 2004 11:09:18 PDT." <20040610180918.GA21898@1-4-5.net> Message-ID: <200406101833.i5AIXOr9009421@rotala.raleigh.ibm.com> David, This is not really a topic for this list, but I can't ignore this either. > Let me suggest that it can get worse. What happens when a > document goes into "Expert Review :: External Party", and > an expert registers comments (that get into the COMMENTS > field), then never responds to the author's response to > the comments? This is one way to effectively block > a document (this is very much like filibuster, only by > silence). If a document gets stuck like this, frustrated parties should contact the Shepherding AD. If that doesn't get a reasonable response, escalate, either by trying other ADs you think might listen, or going directly to Harald (as IETF Chair). But letting documents just sit is not acceptable. I don't think anyone would argue for that. Thomas From braden at ISI.EDU Thu Jun 10 11:42:16 2004 From: braden at ISI.EDU (Bob Braden) Date: Thu Jun 10 11:43:12 2004 Subject: [rfc-i] Five-author maximum? Message-ID: <200406101842.LAA25497@gra.isi.edu> I would like to make some general observations about the author list question, from our viewpoint here in the RFC Editor organization. We initiated the limit on authors, maybe a year ago (? ... how time flies), when we observed a disturbing trend towards RFC author list inflation. One factor driving this inflation seemed to be in increasing involvement of players from industry, particularly the telecomm industry, on the IETF stage. There seemed to be an urge for every company to get their name on RFCs, by having one of their guys as one of the authors, and the author lists were beginning to read like an article on the telecomm or IT industry in the WSJ. This seemed to us to be contrary to the long-standing tradition of individual, not corporate, efforts in the Internet technical community. The other tendency was to include everyone in a WG who contributed to a document. But this is a slippery slope, and we seemed to be starting a serious slide down it. It is true that this is not a new issue. In 1987-89 I chaired the Host Requirements Working Group. The Acknowledgments section of RFC 1122 lists some 25 major contributors, and another 25 who contributed some. In fact, there were probably 4 or 5 people who contributed significant nibbles of text that got incorporated, but it would have been really tough to draw the line. Fortunately, the WG felt comfortable with listing only the Editor on the document, so I did not have to make the judgment on who should be listed (clearly, not 25!) Authorship can of course be a minefield of personal anxiety. Some people care a great deal whether they are included, sometimes even though their contribution has been marginal. A futher problem arises in those cases (perhaps few, these days) when the starting point for an IETF spec was an earlier research effort. Should all those who contributed to the earlier research, but did not help write the subsequent IETF spec, claim authorship on the final RFC? It seems dubious to me, but I have received anguished messages on the topic. It seems that this could logically lead to a BGP4 RFC that carried the names of everyone who had contributed to BGP development over the years! We also note that some academic fields have a tradition of including everyone remotely involved. You not infrequently see articles in Physical Review Letters with 20 to 50 authors. OK, that's their thing, but that has not been the way of the Internet/IETF. We therefore proposed an author list limitation to the IESG and to the community. To help take the sting out, we invented a new official RFC section, the Contributors section. Fortunately, in fact, nearly everyone has accepted the general principle and cooperated in good spirit, and we are the RFC Editor are grateful. The (admittedly slightly arbitrary) limit of 5 has generally worked out. The limit gives WG chairs a stick that they can (and do ;-)) wield to control their author lists. But life is full of exceptions, and Jon Postel taught us to maintain general principles while being willing to Do The Right Thing in special cases. We try to maintain that tradition of principled flexiblity. There have been a (very) few exceptions to the rule-of-5 for author lists, but only after really good arguments were made. The topic of this discussion is the most recent example. Bob Braden for the RFC Editor From braden at ISI.EDU Thu Jun 10 11:49:56 2004 From: braden at ISI.EDU (Bob Braden) Date: Thu Jun 10 11:50:52 2004 Subject: [rfc-i] Status of draft-rfc-editor-rfc2223bis? Message-ID: <200406101849.LAA25513@gra.isi.edu> Paul Hoffman asks: *> *> Greetings again. According to the Internet Drafts tracker, *> draft-rfc-editor-rfc2223bis has been stuck for nine months waiting *> for comments back to the shepherding AD (Harald Alvestrand). Is that *> really true? We reall need this document finished and made an RFC. If *> it isn't true, someone should get the I-D tracker to reflect reality. *> Paul, It may be formally true, but it does not reflect reality. The reality is this: (1) the RFC Editor has generally taken a go-slow attitude on publishing 2223bis. We lived for many years with 2223 as it became more and more out of date. We have wanted to wait for a period of stability before publishing its successor. In the meantime, the I-D pointed to by the RFC Editor web page provides a living document with the latest information. We have thought this sufficient to bridge the gap for the time being. (2) events and people have put a great deal of pressure on the RFC Editor recently, and we have limited resources. Some staff members already put in significant unpaid effort because they believe in the effort. We simply have not had time to do the next update. We hope to do so before San Diego. Bob Braden for the RFC Editor From dmm at 1-4-5.net Thu Jun 10 12:52:59 2004 From: dmm at 1-4-5.net (David Meyer) Date: Thu Jun 10 12:54:01 2004 Subject: [rfc-i] Status of draft-rfc-editor-rfc2223bis? In-Reply-To: <200406101833.i5AIXOr9009421@rotala.raleigh.ibm.com> References: <20040610180918.GA21898@1-4-5.net> <200406101833.i5AIXOr9009421@rotala.raleigh.ibm.com> Message-ID: <20040610195259.GA23155@1-4-5.net> On Thu, Jun 10, 2004 at 02:33:24PM -0400, Thomas Narten wrote: >> David, >> >> This is not really a topic for this list, but I can't ignore this >> either. >> >> > Let me suggest that it can get worse. What happens when a >> > document goes into "Expert Review :: External Party", and >> > an expert registers comments (that get into the COMMENTS >> > field), then never responds to the author's response to >> > the comments? This is one way to effectively block >> > a document (this is very much like filibuster, only by >> > silence). >> >> If a document gets stuck like this, frustrated parties should contact >> the Shepherding AD. If that doesn't get a reasonable response, >> escalate, either by trying other ADs you think might listen, or going >> directly to Harald (as IETF Chair). But letting documents just sit is >> not acceptable. I don't think anyone would argue for that. Thomas, First, let me apologize for the off topic post (I didn't realize that it was off topic). That being said, I didn't say that this situation was acceptable. Nor did I say that any one is arguing that such a situation is desirable/acceptable. Rather, I did say is that it can (and does happen). That much can be stipulated (i.e., is fact). FTR, in the case(s) I know of, everything short of escalating to Harald was done (and more). There is also the issue of not wanting to use a heavyweight mechanism like appealing to the IETF chair to resolve these issues. This both because many of us would rather not put the person who made the comments in that position if possible (consider the possibility that there is a benign reason for the delay), and/or would like to avoid having to escalate anything to the IETF chair level (again, if possible). Dave From paul.hoffman at vpnc.org Thu Jun 10 13:01:41 2004 From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC) Date: Thu Jun 10 13:02:48 2004 Subject: [rfc-i] Status of draft-rfc-editor-rfc2223bis? In-Reply-To: <200406101849.LAA25513@gra.isi.edu> References: <200406101849.LAA25513@gra.isi.edu> Message-ID: At 11:49 AM -0700 6/10/04, Bob Braden wrote: >It may be formally true, but it does not reflect reality. The reality >is this: > >(1) the RFC Editor has generally taken a go-slow attitude on >publishing 2223bis. We lived for many years with 2223 as it became >more and more out of date. We have wanted to wait for a period of >stability before publishing its successor. In the meantime, the I-D >pointed to by the RFC Editor web page provides a living document >with the latest information. We have thought this sufficient >to bridge the gap for the time being. A few things here: - This sets a really bad precedent. It is almost exactly akin to "create your protocol from the Internet Draft that we will keep renewing; we're not going to bother to get an RFC". - The draft expired many months ago, and is only being kept alive because of its status in the queue. Again, a bad precedent for the rest of the IETF. - The link from the RFC Editor's page seems to be broken. doesn't get me anything. >(2) events and people have put a great deal of pressure on the RFC >Editor recently, and we have limited resources. Some staff members >already put in significant unpaid effort because they believe in the >effort. We simply have not had time to do the next update. We hope >to do so before San Diego. This is very confusing. From the ID Tracker, it looks like there is only one small outstanding issue; it should take less than half an hour to fix. Are there issues not listed on the tracker? --Paul Hoffman, Director --VPN Consortium From braden at ISI.EDU Thu Jun 10 13:21:21 2004 From: braden at ISI.EDU (Bob Braden) Date: Thu Jun 10 13:21:58 2004 Subject: [rfc-i] Status of draft-rfc-editor-rfc2223bis? Message-ID: <200406102021.NAA25580@gra.isi.edu> *> *> - This sets a really bad precedent. It is almost exactly akin to *> "create your protocol from the Internet Draft that we will keep *> renewing; we're not going to bother to get an RFC". *> Sorry, I don't get your point. What is wrong with a living document as a bridge. *> - The draft expired many months ago, and is only being kept alive *> because of its status in the queue. Again, a bad precedent for the *> rest of the IETF. It happens. But in fact we should update it, and as I said we will do so before San Diego. *> *> - The link from the RFC Editor's page seems to be broken. *> *> doesn't get me anything. *> !? I just checked from both Explorer and Netscape, and neither had an trouble finding it. Could someone else verify an inability to reach this URL? *> >(2) events and people have put a great deal of pressure on the RFC *> >Editor recently, and we have limited resources. Some staff members *> >already put in significant unpaid effort because they believe in the *> >effort. We simply have not had time to do the next update. We hope *> >to do so before San Diego. *> *> This is very confusing. From the ID Tracker, it looks like there is *> only one small outstanding issue; it should take less than half an *> hour to fix. Are there issues not listed on the tracker? *> Paul, you obviously has no concept of the work needed to run the RFC Editor. Bob Braden *> --Paul Hoffman, Director *> --VPN Consortium *> From sob at harvard.edu Thu Jun 10 13:26:02 2004 From: sob at harvard.edu (Scott Bradner) Date: Thu Jun 10 13:26:45 2004 Subject: [rfc-i] Status of draft-rfc-editor-rfc2223bis? In-Reply-To: <200406102021.NAA25580@gra.isi.edu> Message-ID: <20040610202602.843AF25670B@newdev.harvard.edu> *> - The link from the RFC Editor's page seems to be broken. *> *> doesn't get me anything. works for me Safari on OSX Scott From paul.hoffman at vpnc.org Thu Jun 10 14:10:45 2004 From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC) Date: Thu Jun 10 14:14:46 2004 Subject: [rfc-i] Status of draft-rfc-editor-rfc2223bis? In-Reply-To: <20040610202602.843AF25670B@newdev.harvard.edu> References: <20040610202602.843AF25670B@newdev.harvard.edu> Message-ID: At 4:26 PM -0400 6/10/04, Scott Bradner wrote: > *> - The link from the RFC Editor's page seems to be broken. > *> > *> doesn't get me anything. > >works for me > >Safari on OSX Works for me now; possibly a short-term problem. --Paul Hoffman, Director --VPN Consortium From paul.hoffman at vpnc.org Thu Jun 10 14:13:07 2004 From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC) Date: Thu Jun 10 14:14:48 2004 Subject: [rfc-i] Status of draft-rfc-editor-rfc2223bis? In-Reply-To: <200406102021.NAA25580@gra.isi.edu> References: <200406102021.NAA25580@gra.isi.edu> Message-ID: At 1:21 PM -0700 6/10/04, Bob Braden wrote: > *> > *> - This sets a really bad precedent. It is almost exactly akin to > *> "create your protocol from the Internet Draft that we will keep > *> renewing; we're not going to bother to get an RFC". > *> > >Sorry, I don't get your point. What is wrong with a living document >as a bridge. In the IETF, this is usually considered a Bad Thing. If something is ready to become an RFC, it should become an RFC. Otherwise, people will assume that the "living document" is stable, and if it changes later, there will be ugly surprises. > *> - The draft expired many months ago, and is only being kept alive > *> because of its status in the queue. Again, a bad precedent for the > *> rest of the IETF. > >It happens. But in fact we should update it, and as I said we will do >so before San Diego. Great! --Paul Hoffman, Director --VPN Consortium From john+rfc at jck.com Fri Jun 11 13:21:11 2004 From: john+rfc at jck.com (John C Klensin) Date: Fri Jun 11 13:21:49 2004 Subject: [rfc-i] Re: Status of draft-rfc-editor-rfc2223bis? Message-ID: <9CAA548FCB84097B66705658@scan.jck.com> --On Thu, 10 Jun 2004 14:13:07 -0700, Paul Hoffman / VPNC wrote: >> Sorry, I don't get your point. What is wrong with a living >> document as a bridge. > > In the IETF, this is usually considered a Bad Thing. If > something is ready to become an RFC, it should become an RFC. > Otherwise, people will assume that the "living document" is > stable, and if it changes later, there will be ugly surprises. Paul, I'm not wild about the current state of things either, nor am I wild about the example I'm about to cite, but I think it is important to recognize the resource and priority issues that Bob identifies. I note that 1id-guidelines.txt and the notorious and perhaps unlamented "id-nits" documents where both available online only, that the latter was often enforced as a set of binding rules by the IESG and the former was often (albeit sporadically and inconsistently) enforced by the secretariat. I don't remember a lot of protests about that situation (except from myself), evidence of serious harm caused by it, or people using it as a precedent. The RFC Editor at least aspires to keeping a good balance between consistency and flexibility. best, john From paul.hoffman at vpnc.org Fri Jun 11 14:14:00 2004 From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC) Date: Fri Jun 11 14:19:48 2004 Subject: [rfc-i] Re: Status of draft-rfc-editor-rfc2223bis? In-Reply-To: <9CAA548FCB84097B66705658@scan.jck.com> References: <9CAA548FCB84097B66705658@scan.jck.com> Message-ID: At 4:21 PM -0400 6/11/04, John C Klensin wrote: >I note that 1id-guidelines.txt and the notorious and perhaps >unlamented "id-nits" documents where both available online only, >that the latter was often enforced as a set of binding rules by >the IESG and the former was often (albeit sporadically and >inconsistently) enforced by the secretariat. I don't remember >a lot of protests about that situation (except from myself), >evidence of serious harm caused by it, or people using it as a >precedent. Your memory is probably faulty; I remember this coming up as a topic at least once a year at plenaries, and certainly often in the Apps area with the ADs. > The RFC Editor at least aspires to keeping a good >balance between consistency and flexibility. This is good. However, the document in question is updating an existing RFC that we working group chairs are supposed to enforce. Having a correct new RFC is much better than saying "you must follow this expired Internet Draft" to our document editors who we have been trying to convince to keep their documents up to date. --Paul Hoffman, Director --VPN Consortium From braden at ISI.EDU Fri Jun 11 15:55:12 2004 From: braden at ISI.EDU (Bob Braden) Date: Fri Jun 11 15:55:56 2004 Subject: [rfc-i] Re: Status of draft-rfc-editor-rfc2223bis? Message-ID: <200406112255.PAA25905@gra.isi.edu> *> *> > The RFC Editor at least aspires to keeping a good *> >balance between consistency and flexibility. *> *> This is good. However, the document in question is updating an *> existing RFC that we working group chairs are supposed to enforce. Paul, The RFC Editor is of course grateful for the efforts of the WG chairs in preparing Internet Drafts that will become RFCs with minimum additional work. However, the rules that WG chairs should be using (pardon me, but "enforce" seems a bit overblown) are those set by the IESG in IDChecklist. We have endeavored to ensure that IDChecklist is as consistent with the final RFC rules, defined in RFC 2223bis, as possible, reasonable, and useful. I really think we are beating a dead horse here. Bob Braden *> Having a correct new RFC is much better than saying "you must follow *> this expired Internet Draft" to our document editors who we have been *> trying to convince to keep their documents up to date. *> *> --Paul Hoffman, Director *> --VPN Consortium *> _______________________________________________ *> rfc-interest mailing list *> rfc-interest@rfc-editor.org *> http://www.rfc-editor.org/mailman/listinfo/rfc-interest *> From john at jck.com Fri Jun 11 13:13:50 2004 From: john at jck.com (John C Klensin) Date: Thu Jul 29 06:36:13 2004 Subject: [rfc-i] Re: Status of draft-rfc-editor-rfc2223bis? In-Reply-To: <200406111900.i5BJ04J17741@boreas.isi.edu> References: <200406111900.i5BJ04J17741@boreas.isi.edu> Message-ID: <64901E0E17348BD7EBFFE032@scan.jck.com> --On Thu, 10 Jun 2004 14:13:07 -0700, Paul Hoffman / VPNC wrote: >> Sorry, I don't get your point. What is wrong with a living >> document as a bridge. > > In the IETF, this is usually considered a Bad Thing. If > something is ready to become an RFC, it should become an RFC. > Otherwise, people will assume that the "living document" is > stable, and if it changes later, there will be ugly surprises. Paul, I'm not wild about the current state of things either, nor am I wild about the example I'm about to cite, but I think it is important to recognize the resource and priority issues that Bob identifies. I note that 1id-guidelines.txt and the notorious and perhaps unlamented "id-nits" documents where both available online only, that the latter was often enforced as a set of binding rules by the IESG and the former was often (albeit sporadically and inconsistently) enforced by the secretariat. I don't remember a lot of protests about that situation (except from myself), evidence of serious harm caused by it, or people using it as a precedent. The RFC Editor at least aspires to keeping a good balance between consistency and flexibility. best, john