Steve,
Let's be clear: a DOS attack is something the end point itself can do
very little to prevent, since it usually fails or succeeds upstream of
that end point. Therefore, the end point relies on its upstream ISPs to
"do the right thing" and indeed, each of those ISPs relies on other ISPs
to
Part of the problem here is that a knife may be used as a food utensil or a
weapon. Safe handling, however, is always required, and should be
documented.
I would add two other comments. I tried to locate the RFC for HTTP/0.9,
but the best I could find was a reference to a CERN ftp site for the
It is a complete fallacy that NAT provides any sort of security. It does
no such thing. Security is provide by a firewall, and (more importantly)
by strong security policies that are policed and enforced.
- Original Message -
From: Leonid Yegoshin [EMAIL PROTECTED]
Newsgroups:
From: Bill Manning [EMAIL PROTECTED]
So, of the 7763 visable servers, 45 are improperly configured in the
visable US. tree. Thats 4.53% of those servers being "not well
maintained.
Keith, These two data points seem to bear your assertion out.
It is always possible to do something poorly.
It's also completely naive that source routing is your only threat. One
can break into a NAT. One can forge packets and address them
appropriately. Firewalls prevent this, not NATs.
wo or more ISPs, then you don't
want MEDs to be your PRIMARY selection criteria, but tie breaker when
you're going to the same ISP.
Eliot Lear
-BEGIN PGP SIGNATURE-
Version: PGPfreeware 6.5.3 for non-commercial use http://www.pgp.com
iQA/AwUBOTf9pW6AD2cTbjy4EQLRYQCfWklQuPk1vboU6rGVwo17VNMFd
Mohsen BANAN-Public wrote:
Remember the web (http, ...)?
What was IETF's role in Internet's main modern application?
You mean aside from MIME?
--
Eliot Lear
[EMAIL PROTECTED]
e a unique URL available (use post mode to generate dynamic HTML).
How's that?
--
Eliot Lear
[EMAIL PROTECTED]
Hi Bill,
Postscript files are straightforward for a postscript hacker to
change. I imagine the same is true for pdf files.
If you want to make the files hard to change, try a pgp signature.
I have no problem with that, but it's not enough. I'm interested in
putting something in front of a
Would everybody please stop sending me search results!? Google seems to
have it on the front page. Yahoo doesn't. People are getting mixed
results out of Altavista. [Talk about a dumb message that shouldn't have
been archived ;-].
The document that Christian found on the IETF server is NOT
PROTECTED]
To: Eliot Lear [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; "Mike O'Dell" [EMAIL PROTECTED]
Sent: Friday, September 29, 2000 8:45 AM
Subject: Re: Topic drift Re: An Internet Draft as reference material
--On Thursday, 28 September, 2000 12:02 -0700 Eliot Lear
[EMAIL PROTECTED] wrote:
of lost institutional
memory and I proposed some mechanism as a straw man. I think we are
continuing a mistake by not removing the six month limit on I-Ds. I'll
not repeat the rest of my argument, but I do wish you would address my
point about institutional memory.
--
Eliot Lear
[EMAIL PROTECTED]
, and what additional mechanisms are
needed.
Cheers!
--
Eliot Lear
[EMAIL PROTECTED]
to the MIDCOM
working group.
My apologies for the confusion.
--
Eliot Lear
[EMAIL PROTECTED]
I strongly disagree. IETF essentially "owns" the Internet Protocol
specification and has change control over it.
Well, I still disagree, but at least you've taken a step in the right
direction by being more specific. Internet Architecture is an amorphous
blob.
A small group individuals
Dave,
Technogeeks, perhaps. The vast majority of people on the Internet who are
behind NATs most likely don't even know it.
With all the discussion of Napster and so-called "peer to peer" networking,
I think NATs are going to become far more visible to users as these
applications grow in
You know, the people on this list make great computer scientists, network
architects, application and protocol designers. I'm not so sure how many of
us understand CHI. Some of us like to think we do, but I suspect very few
of us actually do. So, given this, why don't we ask some people who
Lyndon Nerenberg wrote:
For travel planning purposes it's important to me that the location
of the London meeting be announced as early as possible. I doubt
very much I'll be staying in the conference hotel (or anywhere near
it), which means I need to book alternate accomodation as early
Actually, the engineering cost of building IPv6 into operating systems
is already essentially paid. The cost of building it into routers and the
like
is paid. The vendors are all (basically) IPv6-ready.
Valdis,
Your message is generally well put. However, while it is possible to send
the
Perry Geoff,
Quite simply, a bunch of us *are* searching for a paradigm shift. Geoff's
good work in this area reveals the complexity of the whys and wherefores of
the routing system. Given that 8+8 was a serious consideration (and to
some deserves some amount of revisiting -- at least as a
For those who don't know procmail, here is a sample config for just the
IETF-announce list. I think this is what Harald is talking about. Change
the flags if you need locking. YMMV.
MAILDIR=YOUR-HOME-DIRECTORY-HERE
:0
* ^To.*IETF-Announce.*
* ^Subject:.*Last Call:.*
last_calls
:0
*
does the rendezvous location really have to be the original topological
location of the host or is that just how folks started thinking about it?
and given that the rendezvous location has to be somewhere in the network,
how can we get around the problem that that location might become
The IETF list should be reserved for proper technical discussions, such
as the format of RFCs and Internet Drafts, NATs are good/bad/ugly, add
me/remove me messages, and conference location debates.
Have you looked at BEEP? RFC 3080.
Eliot
Dan,
If you have data on interoperability regarding 8-bits, can you send a
pointer? I'd be interested to know just what we could expect to break, and
what we could expect not to break...
Eliot
Christian Huitema wrote:
Your fears appear to be based more on emotions than facts. To the best
of my knowledge, the TCP/IP stack that ships in Windows conforms to
the IETF standards and interoperates with the stacks that ship on
other platforms -- it is certainly meant to. Several Microsoft
Bill,
The field may have been well plowed by NIMROD, but the IETF forgot to
water it. This organization has never sufficiently answered the route
scaling problem, and the ISPs are paying for it today. The question is
really whether IPv6 is properly deployable over the long term without a
Dan,
Were you one of those kids who had trouble following directions? Randy
has given you a pretty plain solution that even my mother could follow
(and my mother barely knows how to find the on button of a computer).
Join the list already. How hard is that for a so-called mail guru?
Eliot
increasingly often I find WGs whose definition of the best possible
outcome is inconsistent with, and in some cases almost diametrically
opposed to, the interests of the larger community.
I have two problems with this statement. First, while I am all for
being critical of our processes for
Paul,
I would settle for the message being logged as dropped on some web site.
Or, if disk space is really an issue, I would also find it acceptable
to have a global IETF whitelist and bounce mail from people who are not
on it. That having been said, I have no problem with the message
Do you constantly run into your fellow convention goers at dinner?
Are you concerned you're getting ripped off by restaurants that serve
low quality food?
Do you feel that you've just stayed five days in a city and know nothing
more about it than when you arrived?
If you answered yes to these
Tony Hain wrote:
Trying to use SL for routing between sites is what is broken.
But that's not all...
The space
identified in RFC 1918 was set aside because people were taking whatever
addresses they could find in documentation.
Not as I recall. Jon Postel received several requests for
Tony Hain wrote:
History shows people will use private address space for a variety of
reasons. Getting rid of a published range for that purpose will only
mean they use whatever random numbers they can find. This has also been
shown to create operational problems, so we need to give them the tool
Ultimately, as I wrote with others some nine years ago, some practices
should not be codified. With IPv4 at least there was a plausible
argument for network 10. I didn't like it, nor did I agree with it, but
it was plausible. The same cannot be said for v6.
Incidentally, Sun HP's use of
Michel,
What you say is possible, and has happened. But dumb things happen.
Those dumb things could happen with non site-local addresses as well.
But look. Ultimately I think we as a community do need to own up to
better tooling, which can lead to better expectations. Also, I don't
see any
Tony Hain wrote:
Margaret Wasserman wrote:
Of course, in the case of site-local addresses, you don't
know for sure that you reached the _correct_ peer, unless you
know for sure that the node you want to reach is in your
site.
Since the address block is ambiguous, routing will assure that
Keith Moore wrote:
HIP only solves part of the problem. It lets you use something besides
an address as a host identity, but it doesn't provide any way of mapping
between that identity and an address where you can reach the host.
That's not entirely true. It doesn't give you a very scalable way
Tony Hain wrote:
The IETF needs to recognize that the ISPs don't really have a good
alternative, and work on providing one. If they have an alternative and
continue down the path, you are right there is not much the IETF can do.
At the same time, market forces will fix that when customers move to
Dave,
Please indicate some historical basis for moving an installed base of
users on this kind of scale and for this kind of reason.
History is replete with examples. From the Internet Worm to Code Red,
consumers do install software when they perceive either a threat or a
benefit. Getting rid
Paul Hoffman / IMC wrote:
At 11:36 PM -0700 5/29/03, Dave Crocker wrote:
The POP-IMAP example is excellent, since it really demonstrates my
point. IMAP is rather popular in some local area network environments.
However it's long history has failed utterly to seriously displace POP
on a global
Can we please move along? Does anyone care to start a mailing list for
technical proposals? If not, perhaps all of these debates are a waste
of bandwidth?!
Eliot
I don't know about about you, Paul, but I'm writing my drafts using
EMACS and Marshall's tool. That allows for generation of HTML, NROFF,
and text. The HTML allows for hyperlinks, which is REALLY nice.
Eliot
Stephen Sprunk wrote:
Or we all just got sick of the bickering and accepted defeat (unlike Tony).
For the record, I can't support deprecating site locals until we have
something else approved to replace them -- at which point I say good
riddance. There are several drafts in the WG to that end
Vernon Schryver wrote:
15 years ago a defining difference between the IETF and the ISO was
that the IETF cared about what happens in practice and the ISO cared
about what happens in theory. As far as I can tell, the IPv6 site
local discussion on both sides is only about moot theories.
Without
The example I'm thinking about involved predecessors to OpenGL.
As this example doesn't even involve communication over a network, I would
agree that it is out of scope. ...
[OpenGL example]
It's not that other examples such as X couldn't have used more network knowledge to
avoid problems
Vernon,
I'm not much for mission statements either. But it's easy to fall into
a Dilbert view of the world, even when such things might actually help.
I think the intent is to derive from some community consensus on goals
how to evolve the organization. And we are at a crossroads. Either we
I have no first-hand information on how much time this costs
So I'll dream up what I think the right number of people should be!
I think part of the blame should go to the access points that kept
disappearing. Someone told me this was because the AP transmitters were
set to just 1 mw. If this
I've argued strongly against NAT, but he's one of those people who seem
to be willing to accept arbitrary amounts of pain (we don't need to
use [protocols that put IP addresses in payload], timeouts aren't
a problem). I'm now pointing him at some relevant RFCs. My question
for the list is is
I realize that the anycast discussion was meant by Karl as an example.
But there was precisely one technical concern I had when discussion got
going. And that was that if something went wrong- meaning that someone
was returning bad data- the IP address wouldn't necessarily provide a
clear
[EMAIL PROTECTED] wrote:
I'd put this a different way. Until PKIs are able to represent the
rich diversity of trust relationships that exist in the real world,
they are mere curiosities with marginal practical value.
That's a true statement whether it's the PKI's fault or not.
I think
Bob,
I agree that many works of great value can be found in early RFCs. But
here's my question to you: if the focus is too much on standards, how do
we scale the process so that we can have great works that are NOT
standards? Clearly neither the IESG nor the IETF need be involved in
that
Dave,
RRSh But of course the whole point is that we don't need this.. at least
RRSh not with SCTP
There is a small matter of getting 500 million hosts to convert to
SCTP and then to convert all Internet applications over to it.
I think this argument can be taken too far. Yes, there are 500
Sam,
As the person who most recently complained, let me elaborate on my
comments. The problem I believe we all are facing is that the
distinction between Proposed, Draft, and Internet Standard has been lost.
I agree with you 100% that...
The point of proposed standard is to throw things out
Keith,
Okay, I read draft-iesg-rfced-documents-00.txt regarding a proposed
change in IESG policy regarding RFC-Ed documents.
I'm opposed to the change, because I believe it would make it too easy
for harmful documents to be published as RFCs.
As I'm sure you well know, the RFC Editor takes
Personally, I'm more concerned by WGs demanding their right to
have their half-baked specifications published as RFCs, and the
for IESG to approve them without any IETF review or other
community review, or (as has happened in the past) even when
substantial oversights or design flaws in those
Keith,
These days, for a protocol specification to be of reasonable use on a
wide scale it needs to avoid causing harm.
First, something can be of reasonable use while still causing harm.
Fossil based fuels prove that. And while I agree that there are certain
areas where causing harm to
In theory there's no reason multicast SYSLOG shouldn't work. The packet
format doesn't need to change and you just need to bind to a multicast
socket. I haven't any idea how implementations will currently behave.
But you're addressing two separate problems- distribution and
reliability.
[EMAIL PROTECTED] wrote:
All,
My two cents worth...
5. Section 3.1 of Carl's Report ( Page 20 ) states Evaluation of
applicants might consist of a search committee appointed by the IETF
Chair. Isn't the appointment of committee members what the IETF
empowers the Nomcom for ?
Not any
Dave Crocker wrote:
The IETF is choosing ISOC to do a job. The IETF is specifying
the job. If the IETF does not like the job that ISOC is doing,
the IETF will get someone else to do it.
And you think that isn't called contractor?
See below.
What label would you use? And how does it describe
Harald Tveit Alvestrand wrote:
John,
what I expected when I caused this poll to be created was that there
would be a significant number of people choosing No, I do not wish to
state an opinion. For multiple reasons - I trust the leadership to
decide better than I can was one that people
Hi Margaret,
My reading of the situation is that the differences between scenarios 0
M revolve around contract and corporate law, potentially in multiple
jurisdictions. I'm not a subject matter expert in this area. If you're
asking that I run this by lawyers, I'd reluctantly do so. But I
Kai Henningsen wrote:
Only Harald disagrees with that, because that is certainly not the
question his poll asked - there was no neither option.
Nor need there be. If the leadership is down to these two choices and
one of them is going to be The Onetm, then you might as well run with
those
the damage. It's happened before. That's
how W3C came to be.
Eliot
John C Klensin wrote:
--On Friday, 01 October, 2004 20:09 +0200 Eliot Lear
[EMAIL PROTECTED] wrote:
Kai Henningsen wrote:
Only Harald disagrees with that, because that is certainly
not the question his poll asked
Spencer Dawkins wrote:
Erk!
I haven't been involved with W3C since 2000, but I WAS involved in W3C
during the late 1990s. It's worth pointing out that the alternate
routing mechanism _did_ include a king - at that time, Tim was doing
final endorsement for all recommendations, and it looks like
Hi Dave,
I am trying to imagine any sort of serious protocol development
process that used that sort of logic and then had acceptance
and/or success.
Here-in lies the rub. If you try to use our rules of protocol
development to develop an organization we'll never get there. And you
and I
Simon,
What is your goal, here? What is it you want to do that you can't do
because of either RFC 3667 or RFC 2026?
Eliot
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
On my way to the dust bin of history, I happened to notice this posting
from Eric S. Raymond:
In what way? Microsoft now knows that with the mere threat of a patent
it either can shut down IETF standards work it dislikes or seize control
of the results through the patent system. The IETF has
Right. While I didn't want to continue this discussion on the IETF
list, as I understand it this is precisely what prefix delegation was
meant to be able to handle.
Eliot
Fred Baker wrote:
At 12:35 PM 11/22/04 -0500, Eric A. Hall wrote:
One potentially technical hurdle here is the way that
Eric S. Raymond wrote:
Indeed. I think this is true. Several people on this list have tried to tell
me that I don't really want the IP address space on my local net to be
decoupled from the server address.
They are wrong. I want to be able to change ISPs by fixing *one* IP
address in *one*
Mike,
As the other co-author to
http://www.ietf.org/internet-drafts/draft-ietf-newtrk-cruft-00.txt,
[...]Its unclear that either the work in progress or the cited drafts
will ever be published as RFCs. Its also unclear that this
(restructuring etc) will be resolved within the 6 month lifetime
Hello,
This is an update from the Old Standards experiment. Below are a list
of proposed standards that are candidates to be obsoleted. The old
standards mailing list has vetted out a good number, but still a good
number remains. We are looking for experts who can say affirmatively
whether
Margaret,
Thanks for your note. Please see below for responses:
Margaret Wasserman wrote:
RFC0885 Telnet end of record option
This option was, at least at one time, used for telnet clients that
connected to IBM mainframes... It was used to indicate the end of a
3270 datastream. I
Bert,
I'll remove it from the list with the expectation that the new MIB will
obsolete the old one. However, I note that is currently not stated in
the header of the draft.
Eliot
Wijnen, Bert (Bert) wrote:
W.r.t.
RFC1269 Definitions of Managed Objects for the Border Gateway
if you did the update and in the process then obsoleted RFC 1618.
Eliot
Carsten Bormann wrote:
On Dec 16 2004, at 12:46 Uhr, Eliot Lear wrote:
RFC1618 PPP over ISDN
We had a short discussion about this in pppext.
The gist was: The document is pretty bad (partly because things were
murky
Eric Rosen wrote:
Let me echo Bob Braden's if it's not broken, why break it? query.
Because maybe it is broke. Even if someone *has* implemented the telnet
TACACS user option, would a user really want to use it? The process is
broke. We say in 2026 that proposed standards should hang around
Eric Rosen wrote:
Even if someone *has* implemented the telnet TACACS user option, would a
user really want to use it?
I don't know. Do you?
Yes, I do. Many of us do. And that's the point.
How do we go about answering a question like that?
We will spend less time discussing that
John,
Harald, while I agree in principle, I would suggest that some of
the comments Eric, Bill, and others have pointed out call for
the beginnings of an evaluation of your experiment. I further
suggest that evaluation is appropriate at almost any time, once
data start to come in.
First a
Elwyn Davies wrote:
Oh, and BTW I can go there on an (air-conditioned) train in only 3 hours.
The USA should invest in a few high speed trains.. they are the world's
best way to travel.
There's a slightly bigger pond between the U.S. and France...
Eliot
Hello,
Does anyone have an archive of the IETF list prior to 1991? I am
specifically looking for 88-90 incl.
Thanks,
Eliot
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Dave,
You make an assumption here that there is some relationship between the
usefulness of a standard done from a working group and those individual
submissions. Is that assumption borne out in truth?
Just asking. I haven't checked too much.
Eliot
Dave Crocker wrote:
On Fri, 07 Jan 2005
On administrative decision the board of directors of non-profit ought to
have final say and we should trust that they're not going to overturn a
decision that causes us to break a contract or otherwise subject us to
liability without VERY good cause.
In short we can't do this stuff without
Keith Moore wrote:
IMHO, charters should not be bound to specific documents. It's one
thing to say WG X will produce a document describing protocol Y, quite
another to say WG X shall publish
draft-ietf-x-joe's-specification-for-y. It's up to the WG, not the
ADs, to decide which
Bruce Lilly wrote:
Such as line breaks in the middle of words, followed by loss of
indentation?
N.B. no smiley.
So what? The nice thing about an XML format is that if you don't like
the representation you can change it without changing the source. Isn't
that nice?!
Eliot
Bruce Lilly wrote:
Not if the primary output is unusable. But maybe I missed your point...
Yes. Don't like the software? Write your own...
Eliot
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Scott W Brim wrote:
I wonder how many of those have actually written a draft using both?
Isn't it sufficient for one to have to have suffered *roff in other
contexts?
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Yakov,
Perhaps the IETF traditional motto, rough consensus and working
code should be revised to make it clear that the rough consensus
goes only up to a certain point, but after that point the IETF
operates solely by a decree from the IESG.
You and I were both in the room when the Ethernet-MIB WG
. In other words, at least this part ain't broke.
Eliot
william(at)elan.net wrote:
On Tue, 19 Apr 2005, Eliot Lear wrote:
Yakov,
Perhaps the IETF traditional motto, rough consensus and working
code should be revised to make it clear that the rough consensus
goes only up to a certain point, but after
Dave Crocker wrote:
the current ietf's track is quite poor, both with respect to timeliness and
quality. quite simply we are taking a long time to turn out lots of
specifications that tend not to get used very much.
I think we can each find examples on either side of this assertion.
MIME took
Margaret,
The words I hate most when I am in a WG meeting are these:
take it to the mailing list
That is usually short for we can't agree in person so we'll now
continue to disagree by email. Debate has been shut off, and usually
prematurely because there is something else on the agenda. I'd
Working groups are expensive. Very expensive.
To me this discussion shows that documents are as expensive as working
groups, and maybe more so. Unless the document is relatively straight
forward, it's easier for someone doing an individual draft to be
funneled to a working group so that
Dave,
You described the charter as a contract between the WG and the rest of
the IETF. I'll argue an alternative below, but let's stick with
contracts for the moment. My basic understanding of contract law tells
me that there are certain real world and legal limitations on contracts
that
Hi Dave,
Dave Crocker wrote:
interesting note. it is always provocative to challenge long-standing precepts,
in this case as per section 2.2 of RFC 2418, Working Group Guidelines, first
published as RFC 1603, in 1994. That does not guarantee that your challenge is
mis-placed but rather that
Rob,
| is whether the proposed mechanism will interfere
| with existing or other proposed mechanisms.
This is totally irrelevant. We're talking about an option. Options,
by their very nature are optional. If use of an option interferes
with some other processing that you require,
Please see below:
Whether that discussion amounted to consensus or not
I wouldn't like to say after all of this time, but it certainly occurred.
Not publicly. Certainly there was a problem. Indeed someone (I forget
who) had made a request for a /8, which forced the issue.
| What
Joe,
It seems like such [IANA] considerations are, by definition, relevant only for
standards-track RFCs. It is not useful to require it for other documents.
I think you're correct in general but this is not always the case.
Consider URI schemes. I think they're often informational, and in
I would point out that it is historically useful to be able to track
changes between draft and full or proposed and draft and we don't list
status information in the RFCs...
Eliot
[EMAIL PROTECTED] wrote:
Hi,
I was wondering if someone could help me out on this one. I was doing a bit
of
For the daring, there is http://www.ofcourseimright.com/~lear/ietf63.ics.
I claim no competence in any of this. No responsibility if you miss
your meetings. No promises to update it. But it works for me.
Eliot
___
Ietf mailing list
Ietf@ietf.org
Thanks for the file. Unfortunately it is not a valid iCalendar file
To fix this, just add the following line below the 'BEGIN:VCALENDAR' line:
VERSION:2.0
Done!
In addition, each VEVENT component needs to have a UID property with a
unique identifier in each one.
Done!
Also, I
An additional update reflecting yesterdays changes is now available at
http://www.ofcourseimright.com/~lear/ietf63.ics.
Additional stuff:
- UIDs *should* be stable across changes.
- An attempt has been made to make proper use of SEQUENCE
- An attempt has been made to parse out LOCATION
Bill,
I couldn't agree with you more regarding multiple overlapping events.
They're all designed for the case where one might double-book, and even
on occasion triple book, but 8 or 9 events? None of them deal with that
correctly. I could go on and on about what these Calendar programs
don't
1 - 100 of 462 matches
Mail list logo
