Re: Naming crap (Re: IESG review of RFC Editor documents)
On 27-mrt-04, at 18:36, Harald Tveit Alvestrand wrote: If we are to change the process that produces this stuff, we HAVE to understand what the reasons are that reasonable, competent people produce things that are sub-par, broken or "crap". And IMHO, we can't do that without saying what these unacceptable results of the process are. [...] I don't think anonymous, class-based criticism will get us much further. We need to be specific about what our problems are. To me it seems that the IETF can't make up its mind: are RFCs just drafts that don't expire, or are they hugely important documents that must be absolutely perfect before they are published? The problem is version control. We're engineers. That means we are, more so than mere mortals, doomed never to get anything right the first time out. However, the RFC publishing model doesn't really allow for incremental changes: you have to write a completely new RFC, which then gets a new number that has no relation to the original RFC. What we need is a way to add information to RFCs whithout the need to rewrite the original RFC or make the new information a full-blown RFC of its own.
RE: Naming crap (Re: IESG review of RFC Editor documents)
In the spirit of "well, if highlighting a difference of opinion is the first step toward resolving it, then we're on our way.": Can we can ask Amazon to include RFCs in their product listings, and then let reviewers, consumers, proponents and objectors to use product rating mechanisms to help guide potential readers of documents as to their "value". The IESG could provide an "editor's rating". I am more than half serious (in terms of "architecture", implementation could be different). regards, peterf
RE: Naming crap (Re: IESG review of RFC Editor documents)
|> -Original Message- |> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On |> Behalf Of Iljitsch van Beijnum |> Sent: Sunday, March 28, 2004 9:38 PM |> To: Harald Tveit Alvestrand |> Cc: IETF Discussion |> Subject: Re: Naming crap (Re: IESG review of RFC Editor documents) |> |> On 27-mrt-04, at 18:36, Harald Tveit Alvestrand wrote: |> |> > If we are to change the process that produces this stuff, |> we HAVE to |> > understand what the reasons are that reasonable, competent people |> > produce things that are sub-par, broken or "crap". And |> IMHO, we can't |> > do that without saying what these unacceptable results of |> the process |> > are. |> |> [...] |> |> > I don't think anonymous, class-based criticism will get us much |> > further. We need to be specific about what our problems are. |> |> To me it seems that the IETF can't make up its mind: are |> RFCs just drafts that don't expire, or are they hugely |> important documents that must be absolutely perfect before |> they are published? |> |> The problem is version control. We're engineers. That means |> we are, more so than mere mortals, doomed never to get |> anything right the first time out. However, the RFC |> publishing model doesn't really allow for incremental |> changes: you have to write a completely new RFC, which then |> gets a new number that has no relation to the original RFC. |> |> What we need is a way to add information to RFCs whithout |> the need to rewrite the original RFC or make the new |> information a full-blown RFC of its own. Personally and from observation it would appear RFCs are stand alone documents that do not get revised. They get superseded by new RFCs covering the same topic. Perhaps the way to approach this particular issue is to provide better navigation aids through the various RFCs so that it is easier for users to find all the related documents showing the relationship (timeline and validity) between the documents. A more involved and comprehensive document management system. Darryl (Dassa) Lynch
Good news
Dear all, With the help of some kindness man, I have got the 'CallPlot', which has been upload to the following address now, http://www.vanstep.com/Download/Code/CallPlot/callplot-0.1.tgz http://www.vanstep.com/Download/Code/CallPlot/callplot-src-0.1.tgz Please take them as you need, they are possible for all over the Internet. :-) Best Regards Baofeng(Felix) Zhang Core Network Department,R&D Buliding F4-2-B008S , Huawei Base, Bantian, Longgang District, Shenzhen 518129 P.R.C. Tel:86-755-28780808 Fax:86-755-28971687 e-Mail:[EMAIL PROTECTED]
Re: Naming crap (Re: IESG review of RFC Editor documents)
From: "Dassa" <[EMAIL PROTECTED]> To: "'Iljitsch van Beijnum'" <[EMAIL PROTECTED]>; "'Harald Tveit Alvestrand'" <[EMAIL PROTECTED]> Cc: "'IETF Discussion'" <[EMAIL PROTECTED]> Sent: Sunday, March 28, 2004 3:37 PM Subject: RE: Naming crap (Re: IESG review of RFC Editor documents) > > Personally and from observation it would appear RFCs are stand alone > documents that do not get revised. They get superseded by new RFCs covering > the same topic. Perhaps the way to approach this particular issue is to > provide better navigation aids through the various RFCs so that it is easier > for users to find all the related documents showing the relationship > (timeline and validity) between the documents. A more involved and > comprehensive document management system. Yes, exactly, and if anyone following this thread has not read http://www.ietf.org/internet-drafts/draft-loughney-what-standards-01.txt yet, that's unfortunate. John Loughney is faithfully working this issue, without a lot of feedback, positive or negative, and he is SO right. My suggestion is to read this draft and provide feedback on Newtrk (http://darkwing.uoregon.edu/~llynch/newtrk.html). Thanks, Spencer
Re: Naming crap (Re: IESG review of RFC Editor documents)
On Sun, 28 Mar 2004, Iljitsch van Beijnum wrote: > Date: Sun, 28 Mar 2004 13:38:13 +0200 > From: Iljitsch van Beijnum <[EMAIL PROTECTED]> > Cc: IETF Discussion <[EMAIL PROTECTED]> > > ... > > To me it seems that the IETF can't make up its mind: are RFCs just > drafts that don't expire, or are they hugely important documents that > must be absolutely perfect before they are published? Why does it have to be one of your two alternatives? RFC's are like books. No book is perfect. Almost all books undergo significant review, copy editing, etc,, before publication. > The problem is version control. We're engineers. That means we are, > more so than mere mortals, doomed never to get anything right the first > time out. However, the RFC publishing model doesn't really allow for > incremental changes: you have to write a completely new RFC, which then > gets a new number that has no relation to the original RFC. While it is normally the case that an RFC is "revised" by the publication of a new RFC which obsoletes the old, this is not necessarily the only way to do it. If there are a significant volume of changes but still only a small amount compated to the size of the original RFC, it is possible to publish and updating RFC, at least for Informational RFCs. See RFC 2801 and 3504. There is also an errata mechanism maintained by the RFC Editor. > What we need is a way to add information to RFCs whithout the need to > rewrite the original RFC or make the new information a full-blown RFC > of its own. There is clearly no way to do what you want with printed books, which are what RFCs are modelled after. To get the effect you want, people would need to go to a web resource or the like. But if they are willing to do that, then they can almost as eaily find out about errata and whether the RFC they are looking for has been obsoleted. I also notice that you ignore all the problems of fluid specifications that constantly change on line so that no two people/implementers can be sure they are working from the same spec unless they agreed on a time stamp, etc. Thanks, Donald == Donald E. Eastlake 3rd [EMAIL PROTECTED] 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA [EMAIL PROTECTED]
Re: I-D ACTION:draft-shore-nat-reachability-00.txt
This I-D does not even mention IPv6 -- any particular reason for not to? :-) Until now, it seems there have been at least 5-10 different NAT traversing/reversing techniques, designed for about every application requiring it. But doing NAT traversal to get IPv6 connectivity would have provided a unified solution to every application... On Fri, 26 Mar 2004 [EMAIL PROTECTED] wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Establishing Reachability Behind NATs > Author(s) : M. Shore > Filename: draft-shore-nat-reachability-00.txt > Pages : 14 > Date: 2004-3-26 > > One of the most persistent, difficult problems introduced with NATs > is voluntary reachability -- a NATted device making itself avail- > able to the public internet. This paper is an overview of the cur- > rent status of reachability, a decomposition of the problem and a > proposal for going forward. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-shore-nat-reachability-00.txt -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: IESG review of RFC Editor documents
--On 28. mars 2004 01:35 +0800 James Seng <[EMAIL PROTECTED]> wrote: Few questions: Thanks, James! 1. Section 4 say that "For documents that are independent of the IETF process: This document is not a candidate for any level of Internet Standard." Does this means that an individual submission can only be Informational only? ie. not even experimental? If so, how does this fit into what happened in IMAA BoF in Seoul? Experimental documents are not (in themselves) candidates for any level of Internet Standard. Revisions of the ideas therein may be - and the same thing can happen to Informationals. This needs to be clearer. (The conclusion is no working group, but wrap up and docs some of the implementations as possibly experimental RFCs via individual submissions) 2. Section 3 talks about the various IESG responses. Most of it makes sense but the last one: "The IESG thinks that this document extends an IETF protocol in a way that requires IETF review, and should therefore not be published without IETF review." It wasn't very clear when will the above apply. It wasn't very clear to me either when I wrote it. Beside, wasn't individual submission already (maybe) subjected to 4 weeks last call? Does this qualify as 'IETF review'? No - the Last Call is only done for standards-track and BCP, not for the Info and Experimental sent in via the RFC Editor. (sometimes we've done it in the past, but it's unlikely to happen under this procedure.) and yes, a 4-week Last Call + the procedure that led an AD to conclude that it was ready for last call *does* qualify as "IETF review"!
Re: IESG review of RFC Editor documents
--On 27. mars 2004 13:12 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: Note: The changed IESG review of RFC Editor documents does NOT change the IESG review for individual submissions to the standards track or individual submission sponsored by an AD. These get full IESG technical review, as before. I assumed that was the case also WG informational and experimental documents I trust? yes!
Re: Naming crap (Re: IESG review of RFC Editor documents)
On Sun, 28 Mar 2004, Donald Eastlake 3rd wrote: > > There is clearly no way to do what you want with printed books, which > are what RFCs are modelled after. To get the effect you want, people > would need to go to a web resource or the like. But if they are willing > to do that, then they can almost as eaily find out about errata and > whether the RFC they are looking for has been obsoleted. > > I also notice that you ignore all the problems of fluid specifications > that constantly change on line so that no two people/implementers can be > sure they are working from the same spec unless they agreed on a time > stamp, etc. Without changing any of the publication process, RFC identification could be changed to more clearly show the history and make it very clear what the current RFC version was by using a -N suffix (where N is an incremental version following the original). No external index would be required to document that RFC xxx-2 supercedes RFC xxx-1. There is a small loss of the obvious time series relationship one can now determine from the simple number. A penalty I'd gladly pay to have obvious documentation of relationships. In the case where an RFC (e.g. abc-3) was superceded by another RFC (e.g., bcd), then RFC abc-4 could be published to be a small placeholder reference to RFC bcd. Whether HTTP/1.1 superceded HTTP/1.0 or was a new -number should be determined by the IESG on the recommendation of the WG/AD. Dave Morris
