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.
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
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
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
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.
granted, but...
an interception proxy that gets the user to a server that
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
On Mon, 10 Apr 2000 07:00:56 EDT, Keith Moore said:
and a technology that only works correctly on the server end seems
like a matter for the server's network rather than the public
Internet - and therefore not something which should be standardized by IETF.
Much the same logic can be applied
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
and a technology that only works correctly on the server end seems
like a matter for the server's network rather than the public
Internet - and therefore not something which should be standardized by IETF.
Much the same logic can be applied to NAT (the way it's usually implemented).
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
In your previous mail you wrote:
But IP-layer interception has some fairly significant limitations
for this application. ...
There's a technical problem with IP intercepting that I've not seen
mentioned, including in the draft. Any intercepting based on TCP or UDP
port
Bottom line is that IP-layer interception - even when done "right" -
has fairly limited applicability for location of nearby content.
Though the technique is so widely mis-applied that it might still be
useful to define what "right" means.
And there you have the argument for publishing
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.
...
client -- Internet - ISP - Intercept - Internet - Server1
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
Bottom line is that IP-layer interception - even when done "right" -
has fairly limited applicability for location of nearby content.
Though the technique is so widely mis-applied that it might still be
useful to define what "right" means.
That sounds overly optimistic.
user
From: Jon Crowcroft [EMAIL PROTECTED]
...
its the 21st century:
f you dont use end2end crypto, then you gotta expect people to optimize
their resources to give you the best service money can buy for the least
they have to spend.
...
That's an interesting idea. People might eventually
From: Vernon Schryver [EMAIL PROTECTED]
Subject: Re: recommendation against publication of draft-cerpa-necp-02.txt
Date: Mon, 10 Apr 2000 10:41:43 -0600 (MDT)
From: Jon Crowcroft [EMAIL PROTECTED]
...
its the 21st century:
f you dont use end2end crypto, then you gotta expect people to
At 11.50 -0400 2000-04-10, Dick St.Peters wrote:
What is the fundamental difference between choosing the best path and
choosing the best source? Arguments that the latter breaks the IP
model are simply arguments that the IP model is broken for today's
Internet and will be even more broken for
Yo Randy!
On Mon, 10 Apr 2000, Randy Bush wrote:
all these oh so brilliant folk on the anti-cacheing crusade should be
sentenced to live in a significantly less privileged country for a year,
where dialup ppp costs per megabyte of international traffic and an
engineer's salary is $100-200
One other item:
Neither this, nor many NAT I-D's, address the particular
issue of sourcing IP addresses not assigned or owned by
the host/gateway, e.g., as they affect the standards
of RFCs 1122, 1123, and 1812.
If a device creates (rewrites) IP source
Bottom line is that IP-layer interception - even when done "right" -
has fairly limited applicability for location of nearby content.
Though the technique is so widely mis-applied that it might still be
useful to define what "right" means.
And there you have the argument for
From: Randy Bush [EMAIL PROTECTED]
...
That's an interesting idea. People might eventually finally start
using end2end crpyto not for privacy or authnetication where they
really care about either, but for performance and correctness, to
defend against the ISP's who find it cheaper to
Peter Deutsch wrote:
g'day,
"Michael B. Bellopede" wrote:
...
Regardless of what occurs at higher layers, there is still the problem of
changing the source address in an IP packet which occurs at the network(IP)
layer.
The Content Services Business Unit of Cisco (Fair Disclosure
its the 21st century:
f you dont use end2end crypto, then you gotta expect people to optimize
their resources to give you the best service money can buy for the least
they have to spend.
...
That's an interesting idea. People might eventually finally start
using end2end crpyto
all these oh so brilliant folk on the anti-cacheing crusade should be
sentenced to live in a significantly less privileged country for a year,
where dialup ppp costs per megabyte of international traffic and an
engineer's salary is $100-200 per month.
and as long as we're talking about just
I tried to send this earlier, but got a response from
[EMAIL PROTECTED] complaining that every line is a bogus majordomo
command. My logs say I sent to [EMAIL PROTECTED] and not [EMAIL PROTECTED]
or anything smilar. I did use the word "s-u-b-s-c-r-i-b-e-r-s" 3 times.
This time I've replaced all
it's completely natural that people will try such approaches -
they are trying to address real problems and they want quick
solutions to those problems.
In particular, they will try such approaches if they are not
presented with better alternatives.
but if the quick fix solutions get
27 matches
Mail list logo
