Re: prohibiting RFC publication

2000-04-09 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 t

Re: prohibiting RFC publication

2000-04-09 Thread Valdis . Kletnieks
On Sun, 09 Apr 2000 11:09:12 EDT, Peter Deutsch in Mountain View said: > 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 o

Re: prohibiting RFC publication

2000-04-09 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-09 Thread Peter Deutsch in Mountain View
g'day, Fred Baker wrote: > 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.

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-09 Thread Patrik Fältström
At 14.35 -0700 2000-04-09, Dave Crocker wrote: >Let's remember that a major goal of these facilities is to get a >user to a server that is 'close' to the user. Having interception >done only at distant, localized server farm facilities will not >achieve that goal. > >Further, I'm unclear about

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 trade

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-09 Thread Dave Crocker
At 03:42 PM 4/9/00 -0800, [EMAIL PROTECTED] wrote: >You are confusing topological locality with administrative locality. I was >talking about the latter, and so, I believe, was Valdis. As my later comment meant to convey, I too was clear about the distinction, but yes I was definitely confused

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 >

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 >po

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-09 Thread ned . freed
> At 01:39 PM 4/9/00 -0800, [EMAIL PROTECTED] wrote: > > > However, I am > > > fully in agreement that interception proxies imposed anyplace other > > > than either endpoint of the connection is a Bad Idea, because a third > > > >Exactly. And after having read this specification, I also think the

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 particip

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-09 Thread Dave Crocker
At 01:39 PM 4/9/00 -0800, [EMAIL PROTECTED] wrote: > > However, I am > > fully in agreement that interception proxies imposed anyplace other > > than either endpoint of the connection is a Bad Idea, because a third > >Exactly. And after having read this specification, I also think these issues >a

Re: prohibiting RFC publication

2000-04-09 Thread Pete Resnick
[Removed IESG and RFC Editor from the recipients] On 4/9/00 at 1:52 PM -0700, Dave Crocker wrote: >Although Pete is attempting to support my comments -- and I equally >concur with his point of view -- in fact I did not say what he >offers as the summary of my statement. What I said was actual

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'

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-09 Thread ned . freed
> On Sat, 08 Apr 2000 15:28:12 EDT, Keith Moore said: > > The simple fact is that I believe that the idea of interception proxies > > does not have sufficient technical merit to be published by IETF, and > > that IETF's publication of a document that tends to promote the use > > of such devices wo

Re: prohibiting RFC publication

2000-04-09 Thread Dave Crocker
At 12:54 PM 4/9/00 -0500, Pete Resnick wrote: >Dave's message only said that technical merit has no bearing on >publication of Informational or This is a good example of the reason this apsect of debate is a major waste of time. Although Pete is attempting to support my comments -- and I equal

Re: prohibiting RFC publication

2000-04-09 Thread Pete Resnick
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 expecte

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 t

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 shou

Re: Patents

2000-04-09 Thread Masataka Ohta
Henning; > The current issue of The Economist discusses the state of the current > patent system. It refers to a site www.bustpatents.com, which may be of > interest in this regard. As usual, the articles there are useless, because: Only a very small percentage of those participating in

Re: prohibiting RFC publication

2000-04-09 Thread Harald Tveit Alvestrand
At 13:51 09.04.2000 -0500, Pete Resnick wrote: >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.

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 Pete Resnick
On 4/9/00 at 12:24 PM -0600, Vernon Schryver wrote: >>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 R

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 tech

Re: prohibiting RFC publication

2000-04-09 Thread Vernon Schryver
> From: Pete Resnick <[EMAIL PROTECTED]> > ... > Dave's message only said that technical merit has no bearing on > publication of Informational or Experimental RFCs. He (nor anyone > else in this thread as far as I can tell) mad no claim that we ought > to determine technical merit on the basi

Constructive IETF patent action(s)

2000-04-09 Thread Dave Crocker
Folks, The time between ietf list discussions about patent issues seems to be getting smaller. Unfortunately, there is not much that the IETF can do about patent law, in the U.S. or elsewhere. (Also, based on my own very limited exposure to that realm, it seems clear that only a very small p

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

Patents

2000-04-09 Thread Henning Schulzrinne
The current issue of The Economist discusses the state of the current patent system. It refers to a site www.bustpatents.com, which may be of interest in this regard. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs