Re: prohibiting RFC publication

2000-04-11 Thread Fred Baker
At 02:38 AM 4/9/00 +0100, Martin J.G. Williams wrote: As far as i'm concerned (IMHO) if the standards bodies were to be driven by the vendors, then they would become no more than sanitised purveyors of de facto standards, and je jure standards would be relegated to being nothing more than

Re: prohibiting RFC publication

2000-04-10 Thread Tripp Lilley
On Sun, 9 Apr 2000, Peter Deutsch in Mountain View wrote: readily accessible. I still see value in having documents come out as "Request For Comments" in the traditional sense, but it certainly wouldn't hurt to find ways to better distinguish between the Standards track and other documents.

Re: prohibiting RFC publication

2000-04-10 Thread Peter Deutsch in Mountain View
g'day, Tripp Lilley wrote: On Sun, 9 Apr 2000, Peter Deutsch in Mountain View wrote: readily accessible. I still see value in having documents come out as "Request For Comments" in the traditional sense, but it certainly wouldn't hurt to find ways to better distinguish between the

Re: prohibiting RFC publication

2000-04-10 Thread Dave Crocker
At 10:33 AM 4/9/00 -0400, Fred Baker wrote: wrestled to the appearance of support as standards. We're all aware of cases where something was poublished as informational, experimental, etc, and the next press release announced support of that "standard", and of cases where RFCs, like IP on

Re: prohibiting RFC publication

2000-04-10 Thread Valdis . Kletnieks
On Sun, 09 Apr 2000 23:01:38 PDT, Dave Crocker [EMAIL PROTECTED] said: At 10:33 AM 4/9/00 -0400, Fred Baker wrote: cases where RFCs, like IP on Avian Carriers, started winding up on RFPs simply because it was an RFC, and therefore "must" be the standard. This is another case of meaning

Re: prohibiting RFC publication

2000-04-10 Thread RJ Atkinson
At 16:09 09-04-00 , Peter Deutsch in Mountain View wrote: Well put. As Dave has pointed out earlier this weekend, there is a burning need for better, permanent access to the Drafts collection. If we had that, perhaps much of this discussion might become moot, since some of the out-on-a-limb

Re: prohibiting RFC publication

2000-04-10 Thread John Stracke
RJ Atkinson wrote: While the folks in this discussion might disagree on which drafts fall in that category, everyone believes that at least some documents ought not be published in an IETF-related archival document series. Mmm...I think the patent thread pointed out that, if we archived all

Re: prohibiting RFC publication

2000-04-10 Thread Keith Moore
The I-D in question has been referred to an existing IETF WG for review, that assertion was made, but not confirmed by the ADs. is it really true? it seems odd because it really isn't in scope for wrec. Keith

Re: prohibiting RFC publication

2000-04-10 Thread John Martin
At 10:39 AM 10/04/00 -0400, Keith Moore wrote: The I-D in question has been referred to an existing IETF WG for review, that assertion was made, but not confirmed by the ADs. is it really true? it seems odd because it really isn't in scope for wrec. Let me jog your memory: At 06:29 PM

Re: prohibiting RFC publication

2000-04-09 Thread Pete Resnick
On 4/8/00 at 5:40 PM -0400, Keith Moore wrote: One would be hard-pressed to inspect the author-list of draft-cerpa-necp-02.txt, the work of the associated companies, and the clear need for optimizations of application performance, and then deem this document not relevant. I'm not

Re: prohibiting RFC publication

2000-04-09 Thread Harald Tveit Alvestrand
At 12:54 09.04.2000 -0500, Pete Resnick wrote: You need to go back and read the message to which you are responding again. Technical merit is specifically *not* a factor in deciding publication of an Experimental or Informational document. For those who believe this, please check out the

Re: prohibiting RFC publication

2000-04-09 Thread Pete Resnick
On 4/9/00 at 8:21 PM +0200, Harald Tveit Alvestrand wrote: For those who believe this, please check out the technical merit of draft-terrell-logic-analy-bin-ip-spec-ipv7-ipv8-05.txt, and ask yourselves if this should be published as an RFC. It should not. See my message to Vernon. But it's

Re: prohibiting RFC publication

2000-04-09 Thread ned . freed
For those who believe this, please check out the technical merit of draft-terrell-logic-analy-bin-ip-spec-ipv7-ipv8-05.txt, and ask yourselves if this should be published as an RFC. It should not. See my message to Vernon. But it's not because it lacks technical merit that it shouldn't

Re: prohibiting RFC publication

2000-04-09 Thread Vernon Schryver
From: Pete Resnick [EMAIL PROTECTED] ...He suggested that we allow them to document current practice. Do I understand correctly that you think that draft-terrell-ip-spec-ipv7-ipv8-addr-cls-02.txt should have been published as an RFC? Uh, no. I see no deployed support for this document

Re: prohibiting RFC publication

2000-04-09 Thread Pete Resnick
On 4/9/00 at 2:06 PM -0600, Vernon Schryver wrote: From: Pete Resnick [EMAIL PROTECTED] Uh, no. I see no deployed support for this document and therefore see no relevance to the Internet community to have this document published. If noone on the Internet is doing it and I'm

Re: prohibiting RFC publication

2000-04-09 Thread Peter Deutsch in Mountain View
g'day, Dave Crocker wrote: . . . It strikes me that it would be much, much more productive to fire up a working group focused on this topic, since we have known of the application level need for about 12 years, if not longer. Which raises the interesting question as to what the

Re: prohibiting RFC publication

2000-04-09 Thread Dave Crocker
At 03:35 AM 4/9/00 -0400, Peter Deutsch in Mountain View wrote: Which raises the interesting question as to what the participants would hope to be the outcome of such a working group and whether we could possibly move towards something ressembling a technical consensus, given the current

Re: prohibiting RFC publication

2000-04-09 Thread ned . freed
On 4/9/00 at 12:39 PM -0800, [EMAIL PROTECTED] wrote: [...]the RFC Editor exercises editorial control over the RFC series, but doesn't specify exactly what editorial control means. Actually, Harald's quote from 2026 does make it pretty clear: Section 4.2.3: The RFC Editor is

Re: prohibiting RFC publication

2000-04-09 Thread Fred Baker
At 03:51 PM 4/8/00 -0700, Karl Auerbach wrote: If the IETF engages in routine non-acceptance of "informational" documents on the basis of non-technical concerns the IETF will, I believe, lose its clear and loud voice when that voice is most needed to be heard. That's a valid concern. The

prohibiting RFC publication

2000-04-08 Thread Dave Crocker
At 05:06 PM 4/8/00 -0400, Keith Moore wrote: Publication under Informational and Experimental has typically been open to all wishing it. uh, no. this is a common myth, but it's not true, and hasn't been true for many years. First, let's be clear that your statement includes a

Re: prohibiting RFC publication

2000-04-08 Thread Keith Moore
One would be hard-pressed to inspect the author-list of draft-cerpa-necp-02.txt, the work of the associated companies, and the clear need for optimizations of application performance, and then deem this document not relevant. I'm not hard-pressed to do this at all. In fact I find it

Re: prohibiting RFC publication

2000-04-08 Thread Karl Auerbach
I'd like note my agreement with to the comments made by Dave Crocker. And I would like to suggest that there is perhaps yet another aspect of this debate: The IETF recently made a strong moral statement against CALEA. That statement carried weight; it was noticed; it had impact. And that

Re: prohibiting RFC publication

2000-04-08 Thread Peter Deutsch
g'day, Keith Moore wrote: One would be hard-pressed to inspect the author-list of draft-cerpa-necp-02.txt, the work of the associated companies, and the clear need for optimizations of application performance, and then deem this document not relevant. I'm not hard-pressed