Doug Royer wrote:
Anthony G. Atkielski wrote:
NAT has obvious disadvantages. ...
... Chat and instant messaging services will fail, and there is no
way to get them to work with NAT.
So far I have not been able to get chat or instant messages services to
fail because
of NAT. (Not that I
Melinda Shore wrote:
...
I'm not sure if you're arguing that there should be a comprehensive
document presenting the technical problems introduced by NATs. I
suspect there should be, although frankly this is one particular
area where there's a clear and growing divide between this community
and
Bob Hinden wrote:
Randy,
as bernard pointed out a while ago, the lack of a review of, and
reference to, the [should be] known literature is notable in many
classes of ietf work and an embarrassing number of internet
drafts.
... and email messages, to wit:
I think the expression that applies to
Vach Kompella wrote:
Melinda,
As a process kind of thing, I'm also concerned about the
growth of the temporary sub-IP area, so I think there are
issues here with both the work itself and in how the IETF
goes about taking on and structuring its work.
And proposals have been made to dismantle
Dave Crocker wrote:
Folks,
For some reason, we continue to make followup discussion a matter of
accident, rather than facilitation.
In line with Don's suggesttion:
We ought to make sure that all I-Ds and RFCs contain contact
information, not just for the authors, but also for the group
[EMAIL PROTECTED] wrote:
It sort of had to start happening. Marriott apparently aims to provide
wireless access at 400 hotels in Germany, the U.K. and the U.S.
FWIW, wireless access != being on the Internet
Many places use NATs and/or firewalls, or require registered MAC
addresses (some
John Stracke wrote:
Pekka Savola wrote:
I would imagine that the IETF as _customers of the hotel_ can do
pretty much what it wants.
Depends on Marriott's contract with Wayport--it probably specifies some
degree of exclusivity. But Wayport might be happy to grant an exception
when they
Eric Rosen wrote:
Keith In my experience, IESG has tremendous breadth - considerably
Keith exceeding that of any single WG.
You must be joking. Or perhaps you just mean that you tend to agree with
the IESG's program of trying to preserve the academic, ivory tower vision of
the
Yakov Rekhter wrote:
Paul,
Er, toning down the rhetoric a bit, it is worthwhile to ask two questions:
- Does keeping the WGs in one area help significantly?
- Does keeping the WGs in the IETF help significantly?
I think it would be worthwhile to ask the following three questions:
I do too.
Scott Bradner wrote:
for what it's worth here is my personal opionion on what we should
do in the question of the sub-ip area
I think we should go with the status quo (with the IESG selecting two
volunteers to manage the area next March)
I do not think that we can make a reasoned decision to do
Vach Kompella wrote:
Let's also let the VRRP WG decide on the fate of SIP WG documents, the CALSCH WG
decide on the fate of OSPF WG docs... Let's particularly ignore the fact that
the folks closest to the issues have the most interest in getting the best
possible outcome.
We don't let WGs
I'm in favor of 1/
3/, again, seems contradictory. The status quo is that it disappears.
Continuing it without a fixed end date is to subversively result in 2/
without a clear charter definition and Nomcom participation.
To be specific, I don't think 3/ should be on the table, at least not
Danny McPherson wrote:
They defined ethernet. It is they who would best determine how to carry
ethernet over another protocol and keep current ethernet correctness.
Sure, but what about IP network correctness (e.g., security or congestion
control)?
Security isn't an IP issue; it's an IPsec
Eric Rosen wrote:
Joe Many of these discussions (layer 2 VPNs, in particular) would be better
Joe served by occuring within the context of their original host
Joe organization (i.e., IEEE for ethernet over IP), since it was those
Joe organizations that defined those LANs, and
Scott W Brim wrote:
On Fri, Dec 06, 2002 08:15:16AM -0800, Joe Touch allegedly wrote:
Eric Rosen wrote:
IEEE is certainly not the right place to determine how to carry
ethernet data and control frames over IP networks.
They defined ethernet. It is they who would best determine how
Harald Tveit Alvestrand wrote:
...
IETF SUB-IP area
...
Although the SUB-IP working groups have made considerable progress
(with 7 RFCs published, another 12 IDs approved for publication, 9 IDs
under IESG consideration and an additional 11 IDs having been passed to
the ADs for their
Danny McPherson wrote:
3. The I in IETF means that the IETF shouldn't be working
sub-IP anyway. Many of these discussions (layer 2 VPNs, in
particular) would be better served by occuring within the context
of their original host organization (i.e., IEEE for ethernet over
.
or give me proof of your claims?
How about proof of the hi-jacking? (sauce for the gander)
Until then, please keep your attacks those who are still able to defend
themselves.
Joe Touch
Director, Postel Center for Experimental Networking
USC/ISI
[EMAIL PROTECTED] would be a fine place to discuss this
further, as it is (by definition) about (albeit recent) Internet history ;-)
Joe
Craig Simon wrote:
I've got a lot of information on this which I'd be happy to share and
exchange, but I still need and want more details. I'm not sure the
Bill Cunningham wrote:
- Original Message -
From: Michel Py [EMAIL PROTECTED]
To: Bill Cunningham [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, September 30, 2002 1:28 PM
Subject: RE: TCP/IP Terms
Bill,
Bill Cunningham wrote:
I think the main goal is to compete with
OSI's
Gary E. Miller wrote:
Yo Joe!
On Fri, 13 Sep 2002, Joe Touch wrote:
Without a dobut you are right, though I think the degree of difference is
awful small. Through hosts with root on switches or through wireless into
the mix and you are back to being roughly equivalent.
Hosts with root
Gary E. Miller wrote:
Yo Joe!
On Mon, 23 Sep 2002, Joe Touch wrote:
root has no problem seeing adjacent UDP even on a switch. Just
overflow the arp cache or poison it.
That all presumes the switch doesn't detect this as an attack and
shutdown that link, which is an entirely reasonable
Kevin C. Almeroth wrote:
Multicast is necessarily a LOT weaker:
1) I can get a copy of packets by normal operation
(join a group). there is no equivalent for UDP,
notably for paths that aren't shared.
Again, not in all cases. You over-simplify the effectiveness of scoping.
Joe Touch wrote:
Gary E. Miller wrote:
...
Barring that, please name ONE switch, or cite ONE credible reference
source, where arpspoofing is prevented at the switch by any means short
of harcoding the MACs.
Practical != economical. Further, there are MACs which are hardcoded
(i.e
Matt Crawford wrote:
Barring that, please name ONE switch, or cite ONE credible reference
source, where arpspoofing is prevented at the switch by any means short
of harcoding the MACs.
Never mind, even hard-coding the MACs to the right ports doesn't
solve the problem. Eve on port X can keep
Kevin C. Almeroth wrote:
It only requires being on a non-IGMP'd switch or a hub; at that point,
you can snoop the traffic and see any packet going to any multicast group.
It's much harder to snoop UDP; for non-broadcast, you'd have to be
in-line (on the wire, effectively) or on a hub. While
Kevin C. Almeroth wrote:
Multicast is necessarily a LOT weaker:
1) I can get a copy of packets by normal operation
(join a group). there is no equivalent for UDP,
notably for paths that aren't shared.
Again, not in all cases. You over-simplify the effectiveness of scoping.
Randy Bush wrote:
joe touch and crew, please turn it off
Jul 15 13:01:45 roam /kernel: arp: unknown hardware address format (0x0800)
As I said at 10:30, and will repeat, this is the result of an arp cache
that hasn't been flushed. An arp cache that we don't control, most
likely
Randy Bush wrote:
joe touch and crew, please turn it off
Jul 15 13:01:45 roam /kernel: arp: unknown hardware address format (0x0800)
As I said at 10:30, and will repeat, this is the result of an arp cache
that hasn't been flushed. An arp cache that we don't control, most
likely on a router
Randy Bush wrote:
We did (at 9:30am, minutes after the problem was detected). It didn't go
away. Now be an engineer and show us a trace.
a bit hard when it is broken arp packets
Jul 15 11:47:27 roam /kernel: arp: unknown hardware address format (0x0800)
Jul 15 11:47:27 roam /kernel:
Peter Deutsch wrote:
g'day,
John C Klensin wrote:
. . .
Please, folks, I am _not_ trying to restart the discussion of
archival I-Ds. Personally, I remain opposed to the idea, and
I believe that they should be treated as drafts and discarded.
If they result in an RFC, then the RFC
Keith Moore wrote:
if respecting the author's wishes isn't reasonable or practical,
it might be that you live in a pretty warped world.
Or a courtroom (or will).
These aren't just wishes; there are valid copyright issues.
Joe
John C Klensin wrote:
Hi.
I've recently had another close encounter with the patent system
and notions of prior art. It occurs to me that we could make a
slight modification to the Internet Draft structure and encourage
including an additional bit of information that would be quite
Lloyd Wood wrote:
Given that a large number of drafts, including even
draft-bradner-submission-rights-00.txt
currently end in a boilerplate saying copyright (year)
or an out-of-date year because the boilerplate has been cut and pasted
from a previous draft, it would be impossible to rely
Bob Hinden wrote:
Ran,
Proprietary is a commonly used term to describe something that
does
not have a full, complete, and open specification -- which is the
current state of IS-IS. Now folks (including me) are trying to fix
that issue by publishing sundry non-standard RFCs on
Rob Austein wrote:
The last time this came up for a TCP implementation I used to
maintain, our interpretation of Robustness Principle applied to this
problem dictated that we shouldn't send segments with checksum fields
set to all ones (that is, we shouldn't send ~(+0)), but that we had to
Marshall Rose wrote:
This is something I have discussed with several people
and every one seems to agree.
The current registration fee of $575 is outrageously
high. Even though IETF claims to be an open forum with
no membership fee - you need $575*3=$1725 per year for
registration fee alone for
Marshall Rose wrote:
Joe - since you replied to my note rather than bonney's, i am obliged
to reply.
Unlike both of you, i am not expressing an opinion on the fees. What i
am saying is that neither of you have any data.
I had data - from other conferences. Granted, I'm asserting there
Patrick R. McManus wrote:
[James M Galvin: Fri, Mar 15, 2002 at 08:40:44PM -0500]
On Fri, 15 Mar 2002, Joe Touch wrote:
These are destination-only addresses, used for forwarding. I tried this
with Mailman (presumably a modern application?), to which I had
subscribed [EMAIL
Patrick R. McManus wrote:
[Joe Touch: Sat, Mar 16, 2002 at 11:21:28AM -0800]
Lists for open discussion should require such hoops for participation,
esp. when there are plenty of reasonable, sufficiently correlated
identifiers than not a list member to identify spam.
...
I think you're
Keith Moore wrote:
Lists for open discussion should require such hoops for participation,
esp. when there are plenty of reasonable, sufficiently correlated
identifiers than not a list member to identify spam.
assuming you meant should not require I'm very much in agreement.
Oops - typed too
Patrick R. McManus wrote:
[Joe Touch: Sat, Mar 16, 2002 at 02:03:22PM -0800]
Patrick R. McManus wrote:
...
The e2e-interest blacklist is new. It appears to be a reaction to the
embarrassing amount of spam that that list has redistributed over the
last couple of years
It's a little over a year
Keith Moore wrote:
Will not the spammers soon learn to send their spams with
one of these addresses as bogus sender?
You overestimate the spammers :-). Most probably have no idea what IETF
is or that they're spamming an IETF list.
I dunno. I've received several complaints from people
James M Galvin wrote:
On Fri, 15 Mar 2002, Joe Touch wrote:
A nontrivial number of users utilize employer-independent email
destinations, such as *@ieee.org, *acm.org, etc.
I'm not willing to write-off that as ignorance of how email works.
Sorry, you lost me here. I
Andrew G. Malis wrote:
Melinda,
I sent an email to the anonymous yahoo ID identified as the mplsissues
list owner to please identify him or herself, and to cease spamming IETF
and other lists.
I also completely agree with Randy's point. Posting to IETF lists
should be restricted to
Andrew G. Malis wrote:
Joe,
I also completely agree with Randy's point. Posting to IETF lists
should be restricted to list participants.
That's often harder to do than it appears, esp. for those who have
multiple mail addresses from which they might reply, or for those on
local
Vernon Schryver wrote:
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Proprietary IP Protocol Type
From: Kuniaki Kondo [EMAIL PROTECTED]
I am working on a distributed router and i want to run my own proprietary protocol
inside over
the IP layer. ...
I also
Bob Braden wrote:
* I don't believe the intent of 2119 was to change the meanings of
* should, must, etc., in RFCs, but rather to define new terms
* SHOULD, MUST, etc., with specific new meanings.
*
* Keith
*
Keith's statement was certainly correct when we first
Aaron Falk wrote:
On Wed, Nov 28, 2001 at 07:44:49PM -0500, Michael H. Warfield wrote:
On Wed, Nov 28, 2001 at 03:05:24PM -0500, Gene Hastings wrote:
Using NAT to connect several of your own computers is one thing.
Using it to connect your neighbors and buddies is quite another. Many
ISP
stanislav shalunov wrote:
NAT is an ugly hack that's impairing people's connectivity, right?
For some, it might be. Others find different faults with NAT.
A highly unusual for an IETFer (and very disturbing) perspective of
cable companies is provided in an article in CED magazine The CAT
Kastenholz, Frank wrote:
At 09:49 AM 10/23/01 -0400, RJ Atkinson wrote:
The challenge is that some folks clearly do use the wireless
LAN to download I-Ds to review precise text during the meeting
discussing that particular I-D (in lieu of carrying paper around,
I suppose), or for
[EMAIL PROTECTED] wrote:
Hi,
I have a question on how to print Internet Draft with the right
pagination on Windows machine.
Take the document below as an example,
http://search.ietf.org/internet-drafts/draft-hain-msword-template-06.txt
If I print this document from Internet
to the Internet. :-)
Joe Touch
Director, PCEN
[EMAIL PROTECTED] wrote:
On Fri, 21 Sep 2001 19:42:23 +0200, Thor Harald Johansen [EMAIL PROTECTED] said:
Is there an Internet standard for the kind of peer-to-peer communication
FreeNet (www.freenetproject.org) is capable of? I think there should be. The
Yes - it's already implemented
Randy Bush wrote:
I.e., layering is, IMO at least, a model. Fine for describing things, but
not necessarily a good blueprint for an implementation.
compilation systems can be constructed which will procuce efficient inlined
code for nicely modularized (layered) source. just not for
Harald Alvestrand wrote:
At 09:03 15/03/2001 +0800, huangjianbo wrote:
I am working on a paper on router, but one problem blocked my process. That
is what's the differents between a switch and a router for the view of
theoritical.
As to the 3 Layer switch and router, both of them work
Dan Cassiday - High End Server Systems wrote:
This note is to announce a new IETF email reflector to discuss methods for
running IP traffic over an InfiniBand fabric. A BOF on this subject
has been proposed for the March IETF meeting.
To join the reflector, send email to [EMAIL
Harald Alvestrand wrote:
At 09:17 08/02/2001 +0100, [EMAIL PROTECTED] wrote:
Anyway, I agree with Mr Gao that it will be usefull to have a distinguishing
name for the last network element, something like ONE "outest network element"
or END "edge netework device" or any other that may be
"Rahmat M. Samik-Ibrahim" wrote:
Joe Touch wrote:
I was not aware that there was ever a proposed STD-1 I-D and/
or last call.
STDs are labels of existing standard RFCs which go through
the usual procedure.
But, neither I was aware that there was ever an I-D and/or a
Brian E Carpenter wrote:
Joe Touch wrote:
...
Speaking of keeping standards, I am wondering why STD-2
is still RFC-1700, although the current version is kept by
IANA at http://www.iana.org/numbers.htm .
Very good question. I'll be glad to raise the issue with IANA;
at least
Ed Gerck wrote:
Keith Moore wrote:
I expressed an opinion that this group should confine itself to addressing
short-term goals rather than trying to make NATs a part of the Internet
architecture.
NATs are already part of the Internet, and gaining share.
An alternate perspective
RJ Atkinson wrote:
At 19:07 03/01/01, Lloyd Wood wrote:
I'd just bounce all emails with non-text attachments with a message
requesting that attachments not be sent to the list, and that the
message be resent as text. Simple. sufficient.
Fully agree. There is no need to use any
Tim Salo wrote:
Date: Tue, 26 Sep 2000 00:02:00 -0700
From: Joe Touch [EMAIL PROTECTED]
Subject: Re: An Internet Draft as reference material
[...]
From RFC 2026, Section 10.3.1. All Contributions:
Reading along further in the same document:
... Internet Drafts
Pete Loshin wrote:
The last RFC I looked at, RFC 2917, has two (of four) references to
"work in progress". No, they don't reference specific I-Ds, but we all
know that "work in progress" is a code word for "some Internet-Draft"
and we all probably have no serious problem tracking down
TSIGARIDAS PANAGIOTIS wrote:
I found this definition in the INTEROP Book of Carl Malamud.
The Internet (note the uppercase "I') is a network infrastructure that
supports reasearch, engineering, education, and commercial services.
The word internet (with a lowercase "i") refers to any
Vernon Schryver wrote:
think we mean having unincumbered availability of the common application
protocols, email, http, ftp, ssh, ...
that's not quite enough; in the UK we're seeing cable-modem ISPs
attempt to restrict services to those applications, or to a subset of
Vernon Schryver wrote:
From: Joe Touch [EMAIL PROTECTED]
...
would pacbell filtering all multicast at all CPE equipemt fall into your
bucket, where do you draw the line?
At IP, as Bob Braden said.
SMTP is _over_ IP.
Multicast _redefines_ IP (or portions
"Theodore Y. Ts'o" wrote:
Date: Thu, 29 Jun 2000 13:22:32 -0400
From: RJ Atkinson [EMAIL PROTECTED]
Actually, IETF has made IEEE 802.11-DSSS the convention for wireless
LANs at all IETF meetings for some time now. This has been supported
at least at Oslo, DC, Adelaide,
RJ Atkinson wrote:
At 16:15 29/06/00 , Joe Touch wrote:
DS appears to be better for large, flat spaces (largely 2-dimensional,
under 3 stories tall, since transcievers on the middle floor largely
cover the upper and lower).
FH is better for more spherical spaces (largely 3
Brian E Carpenter wrote:
Lloyd,
Just to review the actual facts one more time:
The IAB is responsible for the RFC-Editor function under its charter, RFC 2850.
At the IAB's request, the ISOC sub-contracted the RFC-Editor function to ISI.
At the IETF's request (RFC 2026), the ISOC
Harald Tveit Alvestrand wrote:
At 09:22 31.05.2000 -0700, Joe Touch wrote:
It may be useful to distinguish resolver behavior from browser behavior.
If the host has no more specific (explicit) resolver information,
the current fully-qualified hostname, minus the first component
John C Klensin wrote:
--On Friday, June 02, 2000 10:56 AM -0700 Joe Touch
[EMAIL PROTECTED] wrote:
The use of the trailing dot (www.netscape.com.) remains
a useful way to force the resolver to avoid suffix extensions.
And a useful way to induce massive confusion, since many
[EMAIL PROTECTED] wrote:
On Tue, 30 May 2000 23:33:13 EDT, Garreth Jeremiah said:
Excuse me if this is answering the wron question here, but.
This is just cycling through the clients "DNS Suffix search order", which is
clearly set to: dept.other.edu
Not necessarily. Resolvers also
Daniel Senie wrote:
Ian King wrote:
From the reports I read, this was implemented by mapping phone numbers
to some other tag (which the user doesn't see) which is used to get the
calls to the proper carrier and ultimately to the proper user.
Sounds a whole lot like using DNS to map
Anthony Atkielski wrote:
Exactly ... but that's the magic of the variable address scheme. You only
have to allocate disparate chunks in a fixed address scheme because the size
of each chunk is limited by the length of an address field. But if the
address field is variable, you can make
Anthony Atkielski wrote:
I agree! Why create a finite anything when an infinite
possibility exists?
Exactly. If you designed an open-ended protocol, you're far less likely to
ever have to rewrite it.
PS - that's what we have version numbers for.
Open-ended can sometimes mean "you
At 12:02 PM 4/18/00 -0400, Michael B. Bellopede wrote:
Virtual Private Network (VPN) and a Virtual LAN (VLAN) are two unrelated
terms.
VPN deals with security and connecting nodes in a private network across a
public IP internetwork. Read RFC 1853 - IP Tunneling.
1853 is informational.
"BookIII, Robert" wrote:
Joe,
Am I to presume by your statement that you are of the mind that the
time for considering whether vs. which has already come and gone? Is there
anyone on this list who thinks that?
With respect to 'inside the WG', yes, the assumption has been (to me)
...
Joining that mailing list would not be useful, prudent, or honest for
people with sentiments like mine. Moving the question of the wisdom of
such proxies to WREC would be equivalent to moving the question of the
wisdom of wiretapping to the wiretapping working group. At best the
FWIW, there _was_ discussion in WREC of the hazards of transparent web
caching. I dug up an old e-mail, describing the hazards of transparent
web caching which I summarized at the time, when WREC was forming.
A copy of the note, admittedly very rough (just an outline, and a very
rough one at
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
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
401 - 482 of 482 matches
Mail list logo
