[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
> The text in RFC 1902 clause 7.7
> admits multiple interpretations. Until it becomes clear how
> much of an object's semantics are included through reference in an INDEX
> clause, it is only prudent to avoid this particular usage, especially
> since it can be done without impacting protocol interoperability.
But RFC 1902 is clear on the issue you cite:
Note that objects specified in a conceptual row's INDEX clause need
not be columnar objects of that conceptual row. In this situation,
the DESCRIPTION clause of the conceptual row must include a textual
explanation of how the objects which are included in the INDEX clause
but not columnar objects of that conceptual row, are used in uniquely
identifying instances of the conceptual row's columnar objects.
i.e., how much of an object's semantics are included must be specified
by the textual explanation in the DESCRIPTION clause, and this MIB
complies with this requirement. This is one of the areas where the SMI
is not rich enough to provide those semantics in a machine-parsable form.
It may also be worth noting that the editor of this MIB is one of the
co-authors of RFC 1902 as well as the NM Area Advisor to the RMON WG.
> Different compilers react differently to this construct. Some call it
> an error. Others accept it, but generate C code that won't compile.
> Others accept it and generate C code that compiles, but does the wrong
> thing.
It's good that compilers are (at last) extracting more amount of
information out of the SMI's constructs than they used to. However,
those compilers which react incorrectly in this particular situation
are overdoing it; they are trying to extract more information out of
an SMI construct than that construct provides. The compiler that
I'm most familiar with (MOSY) does not have any problems with the
construct.
> It is still worth considering whether the practice of using the same
> variable multiple times in a single INDEX clause is advisable, even
> though not explicitly prohibited by the SMI, especially when there is
> an alternative that does not impact protocol.
I think your use of "not explicitly prohibited" is prejudicial. As I
understand it, the WG did consider this "practice" at its Montreal
meeting and decided to leave the MIB the way it is.
Keith.
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07515;
17 Jul 96 4:12 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07507;
17 Jul 96 4:12 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa03682; 17 Jul 96 4:12 EDT
Received: from ietf.org by ietf.org id aa09974; 17 Jul 96 4:12 EDT
Received: from bells.cs.ucl.ac.uk by ietf.org id aa09970; 17 Jul 96 4:12 EDT
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.08881-0 at bells.cs.ucl.ac.uk>; Wed, 17 Jul 1996 09:11:30 +0100
To: Van Jacobson <van at ee.lbl.gov>
cc: iesg at ietf.org, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: TCP Slow Start, Congestion Avoidance, Fast Retransmit,
and Fast Recovery Algorithms to BCP
In-reply-to: Your message of "Tue, 16 Jul 1996 20:45:04 PDT." <199607170345.UAA17867 at rx7.ee.lbl.gov>
Date: Wed, 17 Jul 1996 09:11:28 +0100
Message-ID: <898.837591088 at cs.ucl.ac.uk>
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
>> that there are limits to its effectiveness (e.g. current
>> algorithm in presence of drop tail fifo routers has minium
>> effective rate of 1 packet per RTT
>You've said this on a number of occasions lately and I think you
>are giving it rather too much emphasis. The congestion control
>and timer algorithms were designed together and work in concert.
um - what i was trying to say was soty of what you've said - that
a) we must reenforce the status of the TCP congestion algorithms
[most ISPs depend on it totally for their nets to give any service at
all)
b) we'd like to re-enforce the idea that RED is probably a lot more
important to deploy (in the immediate term) than, say, WFQ (or RSVP....
and guaranteed or controlled load services)
c) i just wanted to say that there might be more work - an e.g. of
this, if you prefer me to stay away from TCP, is to engieer similar
behaviour (but obviously through different detailed mechanmisms) for
mbone and internet telephony applications on UDP (on ip multicast) so
that they are ISP-friendly too........
agree?
cheers
[and i'm including all your original message to the list coz people
should read it twice:-] !!
>The core of TCP's scalability is it's very conservative, very
>adaptable retransmit timer. Two things happen in the presense
>of congestion: queues increase rapidly which increases the RTT
>seen by users of the path (the biased mean+variance estimator
>tracks these changes and avoids further inflating the queue with
>spurious retransmits), and bottleneck link(s) can't handle the
>agregate input rate and packets get dropped (the exponential
>backoff in the retransmit timer(s) causes the input rate to drop
>to the point where it fits in the bottleneck bandwidth). This
>exponential rate backoff via the retransmit timer is an integral
>part of the TCP adaptation algorithm (in fact, I feel it's the
>primary part & the window adjustment stuff is a second order
>performance tweak). If you were to look at a TCP's behavior as
>you slowly lowered the available bandwidth, you would find it
>varied fairly smoothly down to arbitrarily low rates (as opposed
>to your mental model which seems to have things completely fall
>apart when the bandwidth-delay product falls below 1 packet) --
>all that happens is that TCP modulates the window when the BDP
>is larger than a packet then switches to modulating the time
>between packets. To anticipate a question, no, the packet drop
>behavior doesn't change substantially between these two regimes.
>If you were to plot the number of drops as a function of
>available bandwidth, it would also vary fairly smoothly over the
>entire range.
>
>The problems with running in this timer controlled regime are
>that it's very unfair (because of something nearly identical to
>the ethernet capture effect) and bandwidth upstream of the
>bottleneck(s) is wasted transporting packets that will be
>dropped at the bottleneck (a very serious scaling problem in a
>general mesh network but a problem that people designing
>braindead "loss preference" machinery seem to ignore). But
>that doesn't mean it doesn't work -- it deals with congestion
>quite as well as modulating the window and, in the absense of
>something like RED in the gateways, is only slightly less fair
>(window modulation is also unfair because of an autocatalysis
>effect). RED makes either the window or timer scheme fair.
>
>I think the essense of reliable protocol design is getting the
>timers right. If you do, the protocol will probably work &
>scale (though there may be lots of things you'll have to tweak
>to get good performance). If you botch the timers, the protocol
>is guaranteed to fall apart at some scale (but, unfortunately,
>people are very bad about anticipating the effects of scale & a
>lot of these bench-top grad student projects end up escaping &
>causing no end of suffering for their users before they die). I
>think experience has shown that the TCP designers did a
>remarkably good job on the timers (contemporaries such as X.25 &
>TP-4 completely botched them). It's important to remember that
>they're the protocol's most basic defense against congestion and
>treat them with respect (and occasionally defend them against
>poorly conceived, destablizing "improvements" like the
>collection of mistakes in Arizona's "tcp vegas").
>
> - Van
jon
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09114;
17 Jul 96 7:49 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa05933; 17 Jul 96 7:49 EDT
Received: from ietf.org by ietf.org id aa12338; 17 Jul 96 7:49 EDT
Received: from [204.189.94.35] by ietf.org id aa12277; 17 Jul 96 7:46 EDT
Received: by pilot.firewall.is.chrysler.com; id HAA29575; Wed, 17 Jul 1996 07:45:33 -0400
Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilot.is.chrysler.com via smap (g3.0.1)
id sma029561; Wed, 17 Jul 96 07:45:12 -0400
Received: from rgm3 by mhbclpr2-nf0.is.chrysler.com (8.7.5/SMI-4.1)
id HAA09831; Wed, 17 Jul 1996 07:38:57 -0400 (EDT)
Message-Id: <2.2.32.19960717113602.00bb8cc8 at pop3hub.is.chrysler.com>
X-Sender: t3125rm at pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 17 Jul 1996 07:36:02 -0400
To: Scott Bradner <sob at newdev.harvard.edu>, beuchelt at meteo.uni-koeln.de
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: Has the IETF outlived its Usefulness? (this is what I
tried to
Cc: brian at dxcoms.cern.ch, cook at netaxs.com, dcrocker at brandenburg.com,
ietf at ietf.org, jack at wildbear.on.ca, sob at newdev.harvard.edu
Source-Info: From (or Sender) name not authenticated.
At 06:11 PM 7/15/96 -0400, Scott Bradner wrote:
>> So, the only consequence to be drawn from that is, IMHO, to put an
>> independent "BizNet" into life - parallel to the Internet.
>
>And just what would this BizNet look like?
>what protocols would it run? what applications? how would the
>millions of Internet users get to it?
The AIAG (Automotive Industry Action Group) does not agree with the position
that a BizNet will use different protocols than the Internet. As to
parrallel, well the needs of a BizNet is performance and reliability. As to
the extent that some providers can supply this over some portions(s) of the
Internet, then the Internet will suit the needs of BizNet.
Details at 11.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09397;
17 Jul 96 8:21 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa06333; 17 Jul 96 8:21 EDT
Received: from ietf.org by ietf.org id aa12684; 17 Jul 96 8:21 EDT
Received: from copilot.is.chrysler.com by ietf.org id aa12642;
17 Jul 96 8:20 EDT
Received: by pilotx.firewall.is.chrysler.com; id IAA02256; Wed, 17 Jul 1996 08:20:07 -0400
Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilotx.is.chrysler.com via smap (g3.0.1)
id sma002252; Wed, 17 Jul 96 08:19:58 -0400
Received: from rgm3 by mhbclpr2-nf0.is.chrysler.com (8.7.5/SMI-4.1)
id IAA10370; Wed, 17 Jul 1996 08:13:43 -0400 (EDT)
Message-Id: <2.2.32.19960717121049.00bab1c8 at pop3hub.is.chrysler.com>
X-Sender: t3125rm at pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 17 Jul 1996 08:10:49 -0400
To: Gordon Cook <cook at netaxs.com>, ietf at ietf.org
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: Has the IETF outlived its Usefulness?
Source-Info: From (or Sender) name not authenticated.
To all of you listening here:
COOL IT WITH THE BOOM BOOMS!
Ahem.
Some of us here (well at least this one) have been talking privately with
members of the ILPF ever since they were toying with names like ILTF. Their
goal is to supplement the technical community with an international, legal
perspective to fully round out challenging problems like the DNS.
For those of you have have been on Newdom, it sure sounds like a lot of
legal maneuvering along with the purely administration issues of a DNS.
The challenge for the ILPF is to:
"Thus the particular value of the ILPF is its ability to proceed
in this endeavor as a disinterested neutral organization, with the
skills to deal with the spectrum of issues raised, and following
open policy making processes that meet traditional standards of
administrative due process."
Such a contribution will suit all of us cybercitizens quite well.
The ILPF is still finalizing its organization and is under no obligation to:
At 01:46 PM 7/13/96 -0400, Gordon Cook wrote:
>(who are so far refusing to divulge
>the list of attendees at their innaugural meeting at Netscape headquarters
>this January)
These people spook easily :) and many that they plan on dealing with do so
also. Give them a bit of breathing room, take some of what their vocal
members say with large grains of salt (are they vocal as a policy of the
forming organization, or as an attempt to produce a desired organization),
and be ever viligant on sheparding TECHNINICAL EXCELLENCE. If these people
decree that Pi equals 3 to make someone's life simpler, you will be able to
follow the Internets dictum to route around any such nonsense.
Finally, I really expect to see some very valuable contributions coming from
this forum. In some manner, in time, they will join the ISOC and ITU and
other such organizations in making major POSITIVE contributions to the
global communications community.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09495;
17 Jul 96 8:29 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa06440; 17 Jul 96 8:29 EDT
Received: from ietf.org by ietf.org id aa12893; 17 Jul 96 8:29 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa12812; 17 Jul 96 8:28 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09469;
17 Jul 96 8:28 EDT
Received: from mspost.ic.gc.ca by CNRI.Reston.VA.US id aa06428;
17 Jul 96 8:28 EDT
Received: from Microsoft Mail (PU Serial #1255)
by mspost.ic.gc.ca (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
id AA-1996Jul17.082711.1255.1127323; Wed, 17 Jul 1996 08:30:39 -0400
Sender:ietf-request at ietf.org
From: "Aberdeen, Mark :DGTP" <aberdeen.mark at ic.gc.ca>
To: 'IETF' <ietf at CNRI.Reston.VA.US>
Message-ID: <1996Jul17.082711.1255.1127323 at mspost.ic.gc.ca>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Date: Wed, 17 Jul 1996 08:30:39 -0400
Subject: none
Source-Info: From (or Sender) name not authenticated.
unsubscribe Aberdeen.Mark at ic.gc.ca
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09789;
17 Jul 96 8:53 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09784;
17 Jul 96 8:53 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06774;
17 Jul 96 8:53 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <MAA10441 at pad-thai.cam.ov.com>; Wed, 17 Jul 1996 12:07:34 GMT
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA04280; Wed, 17 Jul 96 08:07:31 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <MAA10438 at pad-thai.cam.ov.com>; Wed, 17 Jul 1996 12:07:30 GMT
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id IAA13367; Wed, 17 Jul 1996 08:07:25 -0400
Message-Id: <199607171207.IAA13367 at winkl.cam.ov.com>
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Cc: John Linn <linn at cam.ov.com>, D.Pinkas at frcl.bull.fr,
dennis.glatting at plaintalk.bellevue.wa.us, cat-ietf at mit.edu,
linn at cam.ov.com
Subject: Re: Regarding sneg-mech
In-Reply-To: Your message of "Tue, 16 Jul 1996 17:10:35 EDT."
<9607162110.AA24337 at dcl.MIT.EDU>
Date: Wed, 17 Jul 1996 08:07:24 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Ted, all:
I think the fact of defining name types as suffixes of mechanism
OIDs is benign, at least until/unless we find ourselves needing
to evolve the notion of independently-defined subtypes to
name type definitions (which would raise the parallel issue
as arises with suboptions to mechanisms). If one mechanism
defines a name type and assigns an OID (from whatever arc) to
represent it, there's no bar to another mechanism's referencing
that OID and also supporting that name type; once the assignment is
made, the fact of the name type and mechanism having being assigned
from the same or different arcs is coincidental, not material.
(It might become hard to dereference, however, if the OID's original
creator later deprecates it while others are relying on its use;
even though a well-behaved OID registry should not reuse an
already assigned value with a conflicting meaning, this starts
to argue for IANA registration here too.)
--jl
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <VAA06848 at pad-thai.cam.ov.com>; Tue, 16 Jul 1996 21:12:16 GMT
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA06068; Tue, 16 Jul 96 17:10:40 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA24337; Tue, 16 Jul 1996 17:10:35 -0400
Date: Tue, 16 Jul 1996 17:10:35 -0400
Message-Id: <9607162110.AA24337 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at MIT.EDU>
To: John Linn <linn at cam.ov.com>
Cc: D.Pinkas at frcl.bull.fr, dennis.glatting at plaintalk.bellevue.wa.us,
cat-ietf at MIT.EDU, linn at cam.ov.com
In-Reply-To: John Linn's message of Tue, 16 Jul 1996 08:56:39 -0400,
<199607161256.IAA13086 at winkl.cam.ov.com>
Subject: Re: Regarding sneg-mech
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Tue, 16 Jul 1996 08:56:39 -0400
From: John Linn <linn at cam.ov.com>
Dennis raises an interesting point. Snego's use of OID suffixing
as a means for representing options within a mechanism is
conceptually clean and compact; when coupled with the hierarchic
rules of OID assignment, however, it carries the implication that
the owner of the mechanism's OID arc must be willing to act as
the registry for any options within that mechanism.
There's another (minor) problem with this. For the Kerberos OID arc, we use
suffixes to the Kerberos mechnaism OID to define the OID's used for
Kerberos Name Type OID's. (see the Kerberos I-D). "It seemed like a
good idea at the time". Other people may have done that as well. This
isn't necessarily be a problem, but I just want to point out that making
assumptions about the structure of an OID name seems to be a little bit
strange, and may cause some unexpected surprises.
- Ted
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12070;
17 Jul 96 10:40 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa08699; 17 Jul 96 10:40 EDT
Received: from ietf.org by ietf.org id aa18241; 17 Jul 96 10:40 EDT
Received: from ng.netgate.net by ietf.org id aa16531; 17 Jul 96 10:33 EDT
Received: from [205.214.160.56] (d59.netgate.net [205.214.160.93]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id HAA28706; Wed, 17 Jul 1996 07:39:57 -0700 (PDT)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v03007820ae12a6e06394 at [205.214.160.56]>
In-Reply-To: <2.2.32.19960717121049.00bab1c8 at pop3hub.is.chrysler.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Wed, 17 Jul 1996 07:23:02 -0700
To: Robert Moskowitz <rgm3 at chrysler.com>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re: Has the IETF outlived its Usefulness?
Cc: Gordon Cook <cook at netaxs.com>, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 5:10 AM -0700 7/17/96, Robert Moskowitz wrote:
>These people spook easily :) and many that they plan on dealing with do so
>also. Give them a bit of breathing room, take some of what their vocal
>members say with large grains of salt (are they vocal as a policy of the
>forming organization, or as an attempt to produce a desired organization),
>and be ever viligant on sheparding TECHNINICAL EXCELLENCE. If these people
>decree that Pi equals 3 to make someone's life simpler, you will be able to
>follow the Internets dictum to route around any such nonsense.
Bob,
What you ask is pretty difficult.
A new activity--with no history in this community--forms and is
represented to the community in a fashion which causes heartburn. You say
we should ignore those vocal spokes-folks and, instead, trust that the
quieter ones will do the right thing.
It's tough to have trust when there is no history. It's tougher
still when those who are from the group and ARE vocal paint an
uncomfortable picture.
As so often turns out, well-intentioned folk need to pay attention
to public relations issue. Being good-hearted isn't good enough.
Recruiting suport is required.
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12650;
17 Jul 96 11:16 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa09277; 17 Jul 96 11:16 EDT
Received: from ietf.org by ietf.org id aa21809; 17 Jul 96 11:16 EDT
Received: from pilot.is.chrysler.com by ietf.org id aa21543; 17 Jul 96 11:11 EDT
Received: by pilot.firewall.is.chrysler.com; id LAA03805; Wed, 17 Jul 1996 11:11:51 -0400
Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilot.is.chrysler.com via smap (g3.0.1)
id sma003791; Wed, 17 Jul 96 11:11:38 -0400
Received: from rgm3 by mhbclpr2-nf0.is.chrysler.com (8.7.5/SMI-4.1)
id LAA14066; Wed, 17 Jul 1996 11:05:22 -0400 (EDT)
Message-Id: <2.2.32.19960717150227.008ff784 at pop3hub.is.chrysler.com>
X-Sender: t3125rm at pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 17 Jul 1996 11:02:27 -0400
To: Dave Crocker <dcrocker at brandenburg.com>
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: Has the IETF outlived its Usefulness?
Cc: Gordon Cook <cook at netaxs.com>, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 07:23 AM 7/17/96 -0700, Dave Crocker wrote:
>
>A new activity--with no history in this community--forms and is
>represented to the community in a fashion which causes heartburn. You say
>we should ignore those vocal spokes-folks and, instead, trust that the
>quieter ones will do the right thing.
As is often the case, a new activity with no history builds quitely off on
the sideline, and just before they break on the front pages there is a leak.
This gives a wider community a view into some of their thought processees,
but not all. Even your IMC started out with a series of quite inquirees to
the 'right people', I seem to recall.
The problem we have here is only the vocal members are stating their views
to the public, while others are not. Heck, I have the same situation in the
AIAG! Business is skitterish, for lots of good reasons. And operates
behind the shield of press releases based on long experience.
To over-react now is not called for. To responding to the vocal members so
that the non-vocal can gage the vocal is also important. The community has
done this, I believe. Until something new comes out of the ILPF there are
two options: join them or wait for new information.
>It's tough to have trust when there is no history. It's tougher
>still when those who are from the group and ARE vocal paint an
>uncomfortable picture.
Tougher still is determining how much baiting is going on. And NO I DO NOT
KNOW IF ANY IS GOING ON. You, yourself have more than just a technical
background and understand the shaping of concensus based on perceived reception.
Trust is the wrong word, here, I think. Wisdom (which I hope some have
gained over the years) is more important.
>As so often turns out, well-intentioned folk need to pay attention
>to public relations issue. Being good-hearted isn't good enough.
>Recruiting suport is required.
And let the lines be drawn. Sigh.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12811;
17 Jul 96 11:31 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12807;
17 Jul 96 11:31 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09519;
17 Jul 96 11:31 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <PAA18067 at pad-thai.cam.ov.com>; Wed, 17 Jul 1996 15:00:43 GMT
Received: from BITSY.MIT.EDU by MIT.EDU with SMTP
id AA06464; Wed, 17 Jul 96 11:00:42 EDT
Received: from postman.osf.org by bitsy.MIT.EDU with SMTP
id AA06519; Wed, 17 Jul 96 11:00:41 EDT
Received: from sulphur.osf.org (sulphur.osf.org [130.105.1.123]) by postman.osf.org (8.7.5/8.7.3) with SMTP id LAA23734; Wed, 17 Jul 1996 11:00:39 -0400 (EDT)
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Rich Salz <rsalz at osf.org>
Received: by sulphur.osf.org (1.38.193.4/4.7) id AA07493; Wed, 17 Jul 1996 10:59:58 -0400
Date: Wed, 17 Jul 1996 10:59:58 -0400
Message-Id: <9607171459.AA07493 at sulphur.osf.org>
To: marc at mit.edu
Subject: Re: Regarding sneg-mech
Cc: cat-ietf at bitsy.mit.edu
> This is IP. You can't prevent a denial of service attack on an
> untrusted network. I can just forge an ICMP host unreachable, or a
> RST, and boom, no more connection.
Does it say anywhere that GSSAPI was intended to be used only
Over the Internet
Over IP
In moderately-hostile untrusted environments
> I seem to remember that this came up in IPSEC, too, and we reached the
> same conclusion.
I'm kinda surprised. Perry hates the SSL cleartext negotiation...
/r$
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12852;
17 Jul 96 11:34 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa09563; 17 Jul 96 11:34 EDT
Received: from ietf.org by ietf.org id aa23092; 17 Jul 96 11:34 EDT
Received: from [199.246.132.198] by ietf.org id aa23021; 17 Jul 96 11:32 EDT
Received: by lacroix.wildbear.on.ca from localhost
(router,SLmailNT V3.0 (alpha 1)); Wed, 17 Jul 96 11:31:34 Eastern Daylight Time
Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca
(199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 1)); Wed, 17 Jul 96 11:31:33 Eastern Daylight Time
X-Sender: "Jack De Winter" <jack at wildbear.on.ca>
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 17 Jul 1996 11:30:35 -0400
To: Robert Moskowitz <rgm3 at chrysler.com>, ietf at ietf.org
Sender:ietf-request at ietf.org
From: Jack De Winter <jack at wildbear.on.ca>
Subject: Re: Has the IETF outlived its Usefulness? (this is what I
tried to
Message-Id: <19960717113134.6714b090.in at lacroix.wildbear.on.ca>
Source-Info: From (or Sender) name not authenticated.
>>And just what would this BizNet look like?
>>what protocols would it run? what applications? how would the
>>millions of Internet users get to it?
>
>The AIAG (Automotive Industry Action Group) does not agree with the position
>that a BizNet will use different protocols than the Internet. As to
>parrallel, well the needs of a BizNet is performance and reliability. As to
>the extent that some providers can supply this over some portions(s) of the
>Internet, then the Internet will suit the needs of BizNet.
okay, assuming that 'BizNet', or a specified portion of the internet that
will be reserved or utilized for business, what are the requirements (in short)
that are needed and how close are we to meeting those needs currently?
regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 576-3873http://www.seattlelab.com/
That which is not explicitly forbidden is guaranteed to occur.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13053;
17 Jul 96 12:02 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa09948; 17 Jul 96 12:02 EDT
Received: from ietf.org by ietf.org id aa23700; 17 Jul 96 12:00 EDT
Received: from ng.netgate.net by ietf.org id aa23638; 17 Jul 96 11:57 EDT
Received: from [205.214.160.56] (d75.netgate.net [205.214.160.111]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id JAA01581; Wed, 17 Jul 1996 09:04:11 -0700 (PDT)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v03007826ae12bc867bd3 at [205.214.160.56]>
In-Reply-To: <2.2.32.19960717150227.008ff784 at pop3hub.is.chrysler.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Wed, 17 Jul 1996 08:56:45 -0700
To: Robert Moskowitz <rgm3 at chrysler.com>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re: Has the IETF outlived its Usefulness?
Cc: Gordon Cook <cook at netaxs.com>, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 8:02 AM -0700 7/17/96, Robert Moskowitz wrote:
>Tougher still is determining how much baiting is going on. And NO I DO NOT
>KNOW IF ANY IS GOING ON. You, yourself have more than just a technical
>background and understand the shaping of concensus based on perceived
>reception.
Bob, since we agree that this is the key issue, let me suggest that
what you are characterizing as premature vocalizations by a stray(?)
portion of the emerging ILTF effort should, in fact, be taken as a good
indication of the forces, processes, and difficulties it will have to deal
with later.
If the response to such uncoordinated speechmaking is indirect
assurances (e.g., from yourself) that we all should ignore the current
speakers and have faith that later speakers will say the right thing, then
I suggest that another key point is being missed.
Those other folks in the ILTF, that you are citing, need to respond
to real world realities. In this case, the real world consists of a vocal
faction who are, in effect (according to your statements), misinterpreting,
overstating, -- otherwise going too far -- what the ILTF is supposed to be
about.
There needs to be a formal, public correction offered.
Consensus is built from information. From what you are saying, we
are being given the wrong info.
Give us the right info.
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14043;
17 Jul 96 14:02 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14039;
17 Jul 96 14:02 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11909;
17 Jul 96 14:02 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <RAA23517 at pad-thai.cam.ov.com>; Wed, 17 Jul 1996 17:13:58 GMT
Received: from BITSY.MIT.EDU by MIT.EDU with SMTP
id AA21080; Wed, 17 Jul 96 13:13:53 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA08891; Wed, 17 Jul 96 13:13:52 EDT
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA21072; Wed, 17 Jul 96 13:13:48 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA24588; Wed, 17 Jul 1996 13:13:46 -0400
Date: Wed, 17 Jul 1996 13:13:46 -0400
Message-Id: <9607171713.AA24588 at dcl.MIT.EDU>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Rich Salz <rsalz at osf.org>
Cc: rja at cisco.com, cat-ietf at bitsy.mit.edu
In-Reply-To: Rich Salz's message of Tue, 16 Jul 1996 23:23:55 -0400,
BAD MSG:
<9607170323.AA04724 at sulphur.osf.org>
ubject: Re: Regarding sneg-mech
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
From: Rich Salz <rsalz at osf.org>
Date: Tue, 16 Jul 1996 23:23:55 -0400
Isn't there a denial-of-service attack? A man-in-the-middle downgrades
the connection to rot-13 instead of 3DES, and as a result the server
refuses to let the client do certain things that it otherwise could.
I am surprised to find that people like the way SSL does its mech
negotiation...
Well, the if either side doesn't think rot-13 is sufficiently strong,
why are they considering that a valid algorithm to offer in the
negotiation. And if the negotiation terminates with an algorithm which
they did not initially offer, then a competent implementation had better
terminate connection ASAP and warn the user of an attempted security
attack!
- Ted
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14064;
17 Jul 96 14:03 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa11930; 17 Jul 96 14:03 EDT
Received: from ietf.org by ietf.org id aa02247; 17 Jul 96 14:03 EDT
Received: from [204.189.94.35] by ietf.org id aa01904; 17 Jul 96 13:47 EDT
Received: by pilot.firewall.is.chrysler.com; id NAA06931; Wed, 17 Jul 1996 13:47:30 -0400
Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilot.is.chrysler.com via smap (g3.0.1)
id sma006916; Wed, 17 Jul 96 13:47:24 -0400
Received: from rgm3 by mhbclpr2-nf0.is.chrysler.com (8.7.5/SMI-4.1)
id NAA17495; Wed, 17 Jul 1996 13:41:07 -0400 (EDT)
Message-Id: <2.2.32.19960717173813.0090c684 at pop3hub.is.chrysler.com>
X-Sender: t3125rm at pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 17 Jul 1996 13:38:13 -0400
To: Jack De Winter <jack at wildbear.on.ca>, ietf at ietf.org
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: Has the IETF outlived its Usefulness? (this is what I
tried to
Source-Info: From (or Sender) name not authenticated.
At 11:30 AM 7/17/96 -0400, Jack De Winter wrote:
>
>okay, assuming that 'BizNet', or a specified portion of the internet that
>will be reserved or utilized for business, what are the requirements (in short)
>that are needed and how close are we to meeting those needs currently?
Simple Jack. Performance and Reliabity. Contractual with liabilities.
A couple ISPs offer this between some of their customers only. Otherwise we
are no where.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14687;
17 Jul 96 15:09 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14683;
17 Jul 96 15:09 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12970;
17 Jul 96 15:09 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <SAA27033 at pad-thai.cam.ov.com>; Wed, 17 Jul 1996 18:28:01 GMT
Received: from BITSY.MIT.EDU by MIT.EDU with SMTP
id AA29687; Wed, 17 Jul 96 14:27:47 EDT
Received: from capone.ch.apollo.hp.com by bitsy.MIT.EDU with SMTP
id AA10093; Wed, 17 Jul 96 14:27:46 EDT
Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id <AA220178063 at capone.ch.apollo.hp.com>; Wed, 17 Jul 1996 14:27:44 -0400
Received: from localhost (sommerfeld at localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with SMTP id OAA00257; Wed, 17 Jul 1996 14:27:39 -0400
Message-Id: <199607171827.OAA00257 at thunk.orchard.medford.ma.us>
X-Authentication-Warning: thunk.orchard.medford.ma.us: Host localhost didn't use HELO protocol
To: Rich Salz <rsalz at osf.org>
Cc: marc at mit.edu, cat-ietf at bitsy.mit.edu
Subject: Re: Regarding sneg-mech
In-Reply-To: rsalz's message of Wed, 17 Jul 1996 10:59:58 -0400.
<9607171459.AA07493 at sulphur.osf.org>
Date: Wed, 17 Jul 1996 14:27:36 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bill Sommerfeld <sommerfeld at apollo.hp.com>
> > I seem to remember that this came up in IPSEC, too, and we reached the
> > same conclusion.
Well, one of the things Photuris had going for it was the use of
cookies as an attempt to defeat a class of active off-path
denial-of-service attacks.
If one does not support rot13, or rc4-40, one does not have to accept
them.
I think that Ran oversimplified a bit -- there are situations where
one might wish to use full-strength crypto with one set of peers, and
weak crypto with others (perhaps because the others aren't allowed to
use real crypto). The policy engines can get arbitrarily hairy (e.g.,
require 128-bit encryption unless the peer's certificate comes from
France, in which case 40-bit crypto is used instead and the peer's
access is correspondingly restricted).
> I'm kinda surprised. Perry hates the SSL cleartext negotiation...
I'll propose for snego what he proposed for SSL:
The `snego' exchange should (logically) be, in sequence:
- cleartext negotiation to find common mechanism
- crypto negotiation to establish mechanism
- exchange of MAC of negotiation parameters
During the third stage, the peers can each verify that the other
received the "offer" which they sent; if they didn't, the negotiation
can be terminated.
Now, this is this is logically three round trips, which is a bit excessive.
We should borrow a trick from SSH and ISAKMP to save a round trip or two:
- We should allow the initiator to "guess" which mechanism will be
accepted, and piggyback the initial token for that mechanism with the
parameters. [The assumption here is that, in realistic cases, the
initiator will guess correctly -- it may have communicated with the
same responder in the past and knows what was acceptable to it then,
or there is a common baseline mechanism in place].
- if the mechanism allows is (e.g., kerberos will allow it), you can
piggyback the MAC of the parameters along with the initial token.
- Bill
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15616;
17 Jul 96 16:23 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa14149; 17 Jul 96 16:23 EDT
Received: from ietf.org by ietf.org id aa07846; 17 Jul 96 16:23 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa07773;
17 Jul 96 16:20 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15546;
17 Jul 96 16:20 EDT
Received: from ns.newbridge.com by CNRI.Reston.VA.US id aa14065;
17 Jul 96 16:20 EDT
Received: (from adm at localhost) by ns.newbridge.com (8.6.12/8.6.12) id QAA11361 for <ietf at CNRI.Reston.VA.US>; Wed, 17 Jul 1996 16:20:06 -0400
Received: from portero(192.75.23.66) by ns via smap (V1.3)
id sma011359; Wed Jul 17 16:20:06 1996
Received: from vienna1.viennasys.com (vienna1.viennasys.com [192.168.204.48]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id QAA17850 for <ietf at CNRI.Reston.VA.US>; Wed, 17 Jul 1996 16:20:05 -0400
Received: from Caroline.viennasys.com (caroline [192.168.204.38]) by vienna1.viennasys.com (8.7.3/8.6.12) with SMTP id QAA05469 for <ietf at CNRI.Reston.VA.US>; Wed, 17 Jul 1996 16:20:42 -0400 (EDT)
Message-Id: <199607172020.QAA05469 at vienna1.viennasys.com>
Comments: Authenticated sender is <csomers at vienna1>
Sender:ietf-request at ietf.org
From: Caroline Somers <csomers at viennasys.com>
Organization: Vienna Systems Corporation
To: ietf at CNRI.Reston.VA.US
Date: Wed, 17 Jul 1996 16:16:09 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: none
Reply-to: csomers at viennasys.com
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.23)
Source-Info: From (or Sender) name not authenticated.
unsubscribe robo at viennasys.com
Caroline Somers tel: +1 (613) 591-3219
Vienna Systems Corporation fax: +1 (613)591-9973
350 Terry Fox Drive, csomers at viennasys.com
Kanata, Ont., Canada K2K 2W5 http://www.viennasys.com
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15866;
17 Jul 96 16:42 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa14478; 17 Jul 96 16:42 EDT
Received: from ietf.org by ietf.org id aa08291; 17 Jul 96 16:42 EDT
Received: from [199.246.132.198] by ietf.org id aa08237; 17 Jul 96 16:41 EDT
Received: by lacroix.wildbear.on.ca from localhost
(router,SLmailNT V3.0 (alpha 1)); Wed, 17 Jul 96 16:39:11 Eastern Daylight Time
Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca
(199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 1)); Wed, 17 Jul 96 16:39:10 Eastern Daylight Time
X-Sender: "Jack De Winter" <jack at wildbear.on.ca>
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 17 Jul 1996 16:39:07 -0400
To: Robert Moskowitz <rgm3 at chrysler.com>, ietf at ietf.org
Sender:ietf-request at ietf.org
From: Jack De Winter <jack at wildbear.on.ca>
Subject: Re: Has the IETF outlived its Usefulness? (this is what I
tried to
Message-Id: <19960717163911.682f3d17.in at lacroix.wildbear.on.ca>
Source-Info: From (or Sender) name not authenticated.
At 01:38 PM 7/17/96 -0400, you wrote:
>At 11:30 AM 7/17/96 -0400, Jack De Winter wrote:
>>
>>okay, assuming that 'BizNet', or a specified portion of the internet that
>>will be reserved or utilized for business, what are the requirements (in
short)
>>that are needed and how close are we to meeting those needs currently?
>
>Simple Jack. Performance and Reliabity. Contractual with liabilities.
>
>A couple ISPs offer this between some of their customers only. Otherwise we
>are no where.
Can you be a bit more precise. Say I wanted to have such things set in motion.
What kind of performance and reliability are we talking about, and what kind
of liabilities typically come into place. Are these realistically achievable
with the current structures?
regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 576-3873http://www.seattlelab.com/
That which is not explicitly forbidden is guaranteed to occur.
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16506;
17 Jul 96 17:57 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16502;
17 Jul 96 17:57 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa15620; 17 Jul 96 17:57 EDT
Received: (from slist at localhost) by merit.edu (8.7.5/merit-2.0) id RAA17085; Wed, 17 Jul 1996 17:47:35 -0400 (EDT)
Resent-Date: Wed, 17 Jul 1996 17:47:35 -0400 (EDT)
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at ietf.org>
Subject: Last Call: The PPP Internetwork Packet Exchange Control Protocol
(IPXCP) to Draft Standard
Date: Wed, 17 Jul 96 17:43:47 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9607171743.aa16348 at IETF.CNRI.Reston.VA.US>
Resent-Message-ID: <"ExIyb3.0.XA4.uyLxn"@merit.edu>
Resent-From: ietf-ppp at merit.edu
X-Mailing-List: <ietf-ppp at MERIT.EDU> archive/latest/1765
X-Loop: ietf-ppp at MERIT.EDU
Precedence: list
Resent-Sender: ietf-ppp-request at merit.edu
The IESG has received a request to consider RFC1552 "The PPP
Internetwork Packet Exchange Control Protocol (IPXCP) as a Draft
Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by July 30, 1996.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07592;
18 Jul 96 8:58 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa06461; 18 Jul 96 8:57 EDT
Received: from ietf.org by ietf.org id aa06366; 18 Jul 96 8:57 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa06234; 18 Jul 96 8:49 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07411;
18 Jul 96 8:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06364;
18 Jul 96 8:49 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07406;
18 Jul 96 8:49 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: IP Version 6 over PPP to Proposed Standard
Date: Thu, 18 Jul 96 08:49:03 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9607180849.aa07406 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "IP Version 6 over PPP"
<draft-ietf-ipngwg-pppext-ipv6cp-03.txt> as a Proposed Standard. This
document is the product of the IPNG Working Group. The IESG contact
persons are Frank Kastenholz and Jeffrey Burgan.
Technical Summary
This document defines the method for transmission of IP Version 6
packets over PPP links as well as the Network Control Protocol for
establishing and configuring the IPv6 over PPP. It also specifies the
method of forming IPv6 link-local addresses on PPP links.
Working Group Summary
The Working Group last call produced no issues with this document.
Protocol Quality
This protocol has been reviewed by Frank Kastenholz and Jeffrey Burgan
of the IESG.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07876;
18 Jul 96 9:03 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa06606; 18 Jul 96 9:03 EDT
Received: from ietf.org by ietf.org id aa06761; 18 Jul 96 9:03 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa06694; 18 Jul 96 9:01 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07699;
18 Jul 96 9:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06526;
18 Jul 96 9:01 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07688;
18 Jul 96 9:00 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: A Method for the Transmission of IPv6 Packets
over FDDI Networks to Proposed Standard
Date: Thu, 18 Jul 96 09:00:49 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9607180900.aa07688 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "A Method for the
Transmission of IPv6 Packets over FDDI Networks"
<draft-ietf-ipngwg-fddi-ntwrks-04.txt> as a Proposed Standard. This
document is the product of the IPNG Working Group. The IESG contact
persons are Scott Bradner and Allison Mankin.
Technical Summary
This memo specifies the MTU and frame format for transmission of IPv6
packets on FDDI networks, including a method for MTU determination in
the presence of 802.1d bridges to other media. It also specifies the
method of forming IPv6 link-local addresses on FDDI networks and the
content of the Source/Target Link-layer Address option used the the
Router Solicitation, Router Advertisement, Neighbor Solicitation, and
Neighbor Advertisement messages described in IPv6 Neighbor Discovery
when those messages are transmitted on an FDDI network.
Working Group Summary
Working Group Last-Call produced no issues with this proposal. The
document was revised based on comments received during IESG
consideration.
Protocol Quality
This document was reviewed for the IESG by Scott Bradner and Allison
Mankin.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07952;
18 Jul 96 9:08 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa06673; 18 Jul 96 9:08 EDT
Received: from ietf.org by ietf.org id aa06915; 18 Jul 96 9:07 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa06809; 18 Jul 96 9:05 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07926;
18 Jul 96 9:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06628;
18 Jul 96 9:04 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07920;
18 Jul 96 9:04 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: cat-ietf at mit.edu
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: The Simple Public-Key GSS-API Mechanism (SPKM) to
Proposed Standard
Date: Thu, 18 Jul 96 09:04:46 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9607180904.aa07920 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "The Simple Public-Key GSS-API
Mechanism (SPKM)" <draft-ietf-cat-spkmgss-06.txt> as a Proposed Standard.
This document is the product of the Common Authentication Technology
Working Group. The IESG contact person is Jeffrey Schiller.
Technical Summary
This document describes a mechanism to be used with the Generic
Security Service API (GSSAPI, RFC1508, RFC1509). It provides for
authentication, integrity, confidentiality and non-repudiation within
the context of GSSAPI. It is based on the use of public key encryption
technology for digital signatures and key distribution. It provides
for the negotiation of the actual cryptographic algorithms to be
employed between communicating entities.
It makes use of X.509 style certificates but does not specify a
particular key hierarchy. The two end points communicating must have a
common hierarchy in common in order for this mechanism to operate,
however a particular hierarchy is not legislated by this document.
Working Group Summary
The CAT working group came to consensus reasonably quickly on these
documents and no comments were received during IETF last call.
Protocol Quality
Jeff Schiller reviewed this document for the IESG and found it to be
competent and reasonable. By adding a public key based mechanism to
the repertoire of mechanisms available under the GSSAPI, this document
adds value to GSSAPI itself.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08226;
18 Jul 96 9:26 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa06966; 18 Jul 96 9:26 EDT
Received: from ietf.org by ietf.org id aa07684; 18 Jul 96 9:26 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa07509; 18 Jul 96 9:23 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08197;
18 Jul 96 9:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06910;
18 Jul 96 9:23 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08191;
18 Jul 96 9:23 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: vgmib at hprnd.rose.hp.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Definitions of Managed Objects for IEEE 802.12
Interfaces to Proposed Standard
Date: Thu, 18 Jul 96 09:23:06 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9607180923.aa08191 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "Definitions of Managed Objects
for IEEE 802.12 Interfaces" <draft-ietf-vgmib-interfaces-mib-06.txt> as a
Proposed Standard. This document is the product of the 100VG-AnyLAN MIB
Working Group. The IESG contact person is Deirdre Kostick.
Technical Summary
This document specifies an extension to the Management Information
Base (MIB) for those devices which contain 100VG-AnyLAN (802.12)
interfaces.
Working Group Summary
This document represents the consensus of the working group; there
was no dissent with the final outcome. The MIB definition is based on
the GDMO from the IEEE 802.12 document.
Protocol Quality
The document has been reviewed for the IETF NM Area by Maria Greene,
and for the IESG by Deirdre Kostick.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08419;
18 Jul 96 9:31 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa07055; 18 Jul 96 9:30 EDT
Received: from ietf.org by ietf.org id aa07848; 18 Jul 96 9:30 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa07722; 18 Jul 96 9:27 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08292;
18 Jul 96 9:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06987;
18 Jul 96 9:27 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08283;
18 Jul 96 9:27 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: aiw-dlsw-mib at www.raleigh.ibm.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Definitions of Managed Objects for Data Link
Switching using SNMPv2 to Proposed Standard
Date: Thu, 18 Jul 96 09:27:11 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9607180927.aa08283 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "Definitions of Managed
Objects for Data Link Switching using SNMPv2"
<draft-ietf-dlswmib-mib-09.txt> as a Proposed Standard. This document
is the product of the Data Link Switching MIB Working Group. The IESG
contact person is Deirdre Kostick.
Technical Summary
This specification defines an extension to the Management Information
Base (MIB) for use with SNMP-based network management. In
particular, it defines objects for configuring, monitoring, and
controlling Data Link Switches (DLSw).
This memo specifies a MIB module in a manner that is both compliant to
the SNMPv2 SMI, and semantically identical to the SNMPv1 definitions.
Working Group Summary
This document reflects the consensus of the working group. There were no
issues raised during the last call.
Protocol Quality
This MIB was reviewed by Kaj Tesink for the IETF NM Area, and
by Deirdre Kostick for the IESG.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09159;
18 Jul 96 10:14 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa07810; 18 Jul 96 10:14 EDT
Received: from ietf.org by ietf.org id aa09093; 18 Jul 96 10:13 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa08928;
18 Jul 96 10:10 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09073;
18 Jul 96 10:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07728;
18 Jul 96 10:10 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09068;
18 Jul 96 10:10 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at CNRI.Reston.VA.US>
Subject: Document Action: OSI NSAPs and IPv6 to Experimental
Date: Thu, 18 Jul 96 10:10:08 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9607181010.aa09068 at IETF.CNRI.Reston.VA.US>
The IESG has reviewed the Internet-Draft "OSI NSAPs and IPv6"
<draft-ietf-ipngwg-nsap-ipv6-01.txt> and recommends that it be published
by the RFC Editor as an Experimental RFC. This document is the product of
the IPNG Working Group. The IESG contact persons are Frank Kastenholz and
Jeffrey Burgan.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09234;
18 Jul 96 10:18 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa07967; 18 Jul 96 10:18 EDT
Received: from ietf.org by ietf.org id aa09356; 18 Jul 96 10:18 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa09129;
18 Jul 96 10:15 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09209;
18 Jul 96 10:15 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07866;
18 Jul 96 10:15 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09203;
18 Jul 96 10:15 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at CNRI.Reston.VA.US>
Subject: Document Action: Uniform Resource Agents (URAs) to Experimental
Date: Thu, 18 Jul 96 10:15:14 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9607181015.aa09203 at IETF.CNRI.Reston.VA.US>
The IESG has reviewed the Internet-Draft "Uniform Resource Agents
(URAs)" <draft-daigle-ura-02.txt> and recommends that it be published
by the RFC Editor as an Experimental RFC. This document is not the
product of an IETF working group. The IESG contact persons are
Keith Moore and Harald Alvestrand.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10591;
18 Jul 96 12:08 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa09897; 18 Jul 96 12:08 EDT
Received: from ietf.org by ietf.org id aa12361; 18 Jul 96 12:08 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa12297;
18 Jul 96 12:05 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10523;
18 Jul 96 12:05 EDT
Received: from hail.ncr.disa.mil by CNRI.Reston.VA.US id aa09826;
18 Jul 96 12:05 EDT
Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id LAA09070; Thu, 18 Jul 1996 11:54:47 -0400 (EDT)
Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01)
id AA837716553; Thu, 18 Jul 96 11:58:22 EST
Date: Thu, 18 Jul 96 11:58:22 EST
Sender:ietf-request at ietf.org
From: "C.Joe Pasquariello" <pasquarc at ncr.disa.mil>
Message-Id: <9606188377.AA837716553 at ncr.disa.mil>
To: Paul Mockapetris <pvm at home.net>
Cc: IETF at CNRI.Reston.VA.US
Subject: Re: Has the IETF outlived its Usefulness? (this is what I
Source-Info: From (or Sender) name not authenticated.
PAUL -
I believe that your characterization below of the ISOC 'absorption' of
the IETF is considerably overstated, and possibly counterproductive to
the recently completed good work of the Poised Group.
The ISOC is focussed on high level policy and process matters
concerning the global health and welfare of the Internet. It has no
intention, nor has it ever [in my experience] acted to intervene in
the main-stream technical work of the IETF. In fact - it provides [and
has provided] a globally recognized and respected voice for the strong
endorsement of the IETF process which we all know and love!
C.Joe P-->
US DoD
______________________________ Reply Separator _________________________________
Subject: Re: Has the IETF outlived its Usefulness? (this is what I
Author: Paul Mockapetris <pvm at home.net> at smtp
Date: 7/15/96 6:12 PM
Gordon,
If the IETF is remiss with regard to the DNS admin issue, it is because it
has not chosen to become involved. The general IETF bottom line has been to
cede DNS admin and even IETF admin responsibility to the ISOC. Some,
including myself, would like to see the IETF take its fate into its own
hands, but they are (more than) neutralized by ISOC faithful, and the
majority of IETF folks find these issues uninteresting and tedious. For
good or ill, the IETF will probably ignore its absorption (by the latest
POISED documents) into the ISOC.
In any case, as you have seen, there's no shortage of parties willing to be
in charge, so the IETF need not get involved unless it has a fresh agenda.
paul
@Home main: 415-944-7200
385 Ravendale direct: 415-944-7221
Mountain View, CA 94043
======================================================================
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13870;
18 Jul 96 17:01 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13866;
18 Jul 96 17:01 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14982;
18 Jul 96 17:01 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <UAA02066 at pad-thai.cam.ov.com>; Thu, 18 Jul 1996 20:28:56 GMT
Received: from BITSY.MIT.EDU by MIT.EDU with SMTP
id AA26447; Thu, 18 Jul 96 16:28:54 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA02440; Thu, 18 Jul 96 16:28:53 EDT
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA26436; Thu, 18 Jul 96 16:28:50 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA25082; Thu, 18 Jul 1996 16:28:49 -0400
Date: Thu, 18 Jul 1996 16:28:49 -0400
Message-Id: <9607182028.AA25082 at dcl.MIT.EDU>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Bill Sommerfeld <sommerfeld at apollo.hp.com>
Cc: Rich Salz <rsalz at osf.org>, marc at mit.edu, cat-ietf at bitsy.mit.edu
In-Reply-To: Bill Sommerfeld's message of Wed, 17 Jul 1996 14:27:36 -0400,
BAD MSG:
<199607171827.OAA00257 at thunk.orchard.medford.ma.us>
ubject: Re: Regarding sneg-mech
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Wed, 17 Jul 1996 14:27:36 -0400
From: Bill Sommerfeld <sommerfeld at apollo.hp.com>
> I'm kinda surprised. Perry hates the SSL cleartext negotiation...
I'll propose for snego what he proposed for SSL:
The `snego' exchange should (logically) be, in sequence:
- cleartext negotiation to find common mechanism
- crypto negotiation to establish mechanism
- exchange of MAC of negotiation parameters
During the third stage, the peers can each verify that the other
received the "offer" which they sent; if they didn't, the negotiation
can be terminated.
This is also exactly what I ended up using to protect the telnet
authentication option, except that I used the optimization which Bill
proposed:
- if the mechanism allows is (e.g., kerberos will allow it), you can
piggyback the MAC of the parameters along with the initial token.
It's a pretty natural and obvious way of doing things, as we can see as
it apparently has been independently re-invented a number of times
already!
- Ted
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13903;
18 Jul 96 17:03 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13899;
18 Jul 96 17:03 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa15009; 18 Jul 96 17:03 EDT
Received: from ietf.org by ietf.org id aa03660; 18 Jul 96 17:03 EDT
Received: from copilot.is.chrysler.com by ietf.org id aa03646;
18 Jul 96 17:02 EDT
Received: by pilotx.firewall.is.chrysler.com; id QAA08882; Thu, 18 Jul 1996 16:52:19 -0400
Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilotx.is.chrysler.com via smap (g3.0.1)
id sma008879; Thu, 18 Jul 96 16:51:56 -0400
Received: from rgm3 by mhbclpr2-nf0.is.chrysler.com (8.7.5/SMI-4.1)
id QAA09931; Thu, 18 Jul 1996 16:45:32 -0400 (EDT)
Message-Id: <2.2.32.19960718204218.0099c534 at pop3hub.is.chrysler.com>
X-Sender: t3125rm at pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 18 Jul 1996 16:42:18 -0400
To: iesg at ietf.org, iab at isi.edu, ietf at ietf.org
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: ILPF: some points of clarification and reflection
Peter has said that I can forward this message to the technical community.
I hope it clears up a little of the ILPF's potential role in the total
Internet community.
>Return-Path: <pfh at netscape.com>
>X-Sender: pfh at corpmail
>Date: Wed, 17 Jul 1996 22:58:27 -0700
>To: iltf-news at osc.edu, iltf-dev at infomeister.osc.edu, dev at global.ilpf.org,
> farber at central.cis.upenn.edu, rgm3 at chrysler.com, djohns06 at counsel.com,
> 76010.2523 at compuserve.com, bobf at corsearch.com,
> carl at starfish.netscape.com, heath at linus.isoc.org, jenglund at itaa.org,
> aireland at starfish.netscape.com, ceh at stanford.edu, perritt at law.vill.edu,
> david.post at counsel.com, roberta at starfish.netscape.com, ekirsh at aol.com,
> rplesser at pipermar.com
>From: pfh at netscape.com (Peter Harter)
>Subject: ILPF: some points of clarification and reflection
>
>Hello Denizens of Internet Law and Policy Lists and Threads -
>
>First, my apologies in advance for any duplication this message may bring
>to your email in-box. Second, I also apologize for being quiet during some
>of the thrashing about lately about the ILPF, domain names, and related
>threads and posts. I have been swamped at my day job and am only now
>reading through the 200+ messages that have piled up. Also, a number of
>friends and colleagues have telephoned me about their concerns and comments
>regarding the issues raised during the last week or so. I have been
>thinking and reflecting a little bit about where the ILPF has come from,
>where it is today, and where it is going.
>
>
>Some Context.
>
>Generally speaking the ILPF is an idea for interested parties to contribute
>substantive input and reaction to law and policy issues of relevance to the
>growth and development of the Internet. ILPF started out (as the ILTF) as
>a gut reaction to some misguided legislation that resulted in the CDA.
>
>While the CDA has been thrown out in court, in retrospect it may have been
>better for all interests considered to have had some substantive precedent
>or opinion to start from. Some sort of thorough, expert, globally vetted
>spade work. Perhaps a collection of industry practices and a record of
>public comment and other relevant input, gathered over a period of time
>from a variety of sources globally. Such a substantive record could have
>been used as a tool by those directly pounding the pavement in Congress
>trying to defend the Internet to an audience who knew little about
>computers let along online communications.
>
>Instead, such a record was not produced until litigation ensued. The
>opinion of the Philadelphia court is a wonderful record and defense of the
>Internet. Next time, however, litigation may not turn out the desirable
>result notwithstanding the tremendous effort waged by industry, policy
>groups, and the Net itself as illustrated by the efforts of groups such as
>VTW, EFF, CDT, among others
>
>
>ILPF Activities In 1996.
>
>Since the inception of the idea in March of 1995 and the exposure of it to
>various fora (e.g., CIX/ISOC Summit, San Diego, April 1995; INET'95;
>Internet Law Symposium, October 1995, Seattle), many individuals and
>entities have expressed significant interest in learning about the ILPF and
>how to become involved. Many volunteers have contributed hundreds of hours
>and in-kind contributions of resources toward growing and spreading the
>idea for some way to organize input on Internet law and policy issues and
>to project it to policy makers in government for reaction, comment,
>revision, and possible implementation in some other form.
>
>By October 1995 some of the early volunteers realized that the idea had to
>move forward into some sort of manifestation if it were to have any teeth.
>Such a change would require some level of resources and some level of
>organizational activity.
>
>I volunteered to host a private meeting on a Saturday at Netscape (my
>employer) and invited colleagues from industry to see if they would be
>willing to support some sort of testbed phase of organization that would
>try to produce a white paper or similar work product on an issue of
>interest. It was given that this experiment was to be largely fueled by
>volunteer time from the representatives of the companies who believed it
>worth their while to make a leap of faith and support the development of
>the idea for an ILPF.
>
>Since that meeting in January 1995 some progress has been made. Nearly 25
>companies are actively involved in the development phase. Four working
>groups have been commenced.
>
>However, because the experiment has been largely on the shoulders of the
>volunteers from the supporting companies, the administrative and
>operational requirements to move the working groups forward have grown so
>large so as to slow our progress.
>
>Had the working groups moved more rapidly when they were initiated in May
>the substance of their work would have been available by now. Critics and
>commentaries of the ILPF would have been able to post comments to the
>drafts of the working groups.
>
>Recent Events & Activity.
>
>Criticism is a good thing. It shakes up those who are so close to the
>center of things that they risk losing perspective. However, some of the
>sniping that has been going on isn't particularly helpful. Misinformation
>and disinformation leads only into a circular debate of what may or may not
>have been said or done by someone.
>
>The ILPF development committee (i.e., those volunteers from the supporting
>companies) realizes that some sort of administrative support is necessary.
>As a result we are allocating some of the funds raised for this
>organizational phase to start such an activity. A web site, faqs,
>guestbook, newsgroups, and a central point of contact who can respond fully
>to questions, comments, and concerns. And once the organizational phase is
>ended and if the supporting companies feel that it would be good to go
>forward, a press release would be in order to formally state who is
>involved.
>
>I do not have the authority to speak on the behalf of the other companies
>supporting the development phase of the ILPF. However, we do have the
>right to the freedom of association by private meeting. The ILPF does not
>have a "secret" or some sort of conspiratorial mandate from anyone or
>anything and it does not believe that its actions are binding on anyone or
>anything. It is hoped, however, that the fact that these industry
>stakeholders are taking the time to produce useful policy findings that may
>add weight to the issues and stem the tide of ill-thought legislation and
>regulation. What happens to the work product depends largely on what
>governments, users, and others think of it.
>
>Ultimately, the ILPF won't succeed unless the work product is of merit.
>The supporting companies won't see the value in continuing and the users
>of the Internet will either flame it or ignore it. I think this is no
>small task.
>
>
>What Is Ahead For the ILPF?
>
>IMHO the biggest goal is to gain the greatest global perspective possible.
>However, this goal has slowed down the organizing a bit. Many companies
>are very interested in the ILPF. However, they don't want to get formally
>involved in the development of the idea until some substantive work product
>is produced. Others want to wait and see and evaluate it after it has
>already taken shape. Others are unsure if it duplicates their activities
>with industry trade associations.
>
>Classic chicken and the egg situation. The ILPF cannot produce credible
>work product unless the input is from all over the world. Corporate
>supporters can't contribute until they see work product. What to do?
>
>Make do with who believes early on and do your best to move forward and
>persist by gaining new participants and by producing substantive work
>product that people can evaluate and react to.
>
>
>Accountability Issues.
>
>Some concern has been expressed about what ILPF is doing vis a vis various
>governments. Informal contact with a few national and regional entities
>has occurred. Some of the volunteers who come in contact with such
>entities as a regular part of their day jobs were able to share the idea
>for an ILPF with these entities and to gauge their reactions. General
>reactions ranged from interest to when can it (i.e., the ILPF) do something
>we can see to who is involved and to how it got started. As with the user
>community and corporate supporters, the ILPF won't mean much of anything to
>government entities until it produces substantive work product and takes on
>comment, and provides a useful process.
>
>The working groups will bear the brunt of the accountability burden. Much
>of it depends on who is on the working groups. Fortunately, none of the
>ILPF working groups are concluded. None are that far along either. Hence,
>the issue of openness and inclusiveness can be better address by the ILPF
>in the near term and during the development phase of the ILPF.
>
>If the ILPF emerges from this current "proof-of-concept" organizational
>phase it aims at becoming a NGO supported by and for international,
>for-profit
>companies, hoping to develop consensus views on relevant topics, which
>consensus might be well-received in part because of the
>stature of the ILPF membership. The working groups commissioned by the
>ILPF and financial supported by the ILPF would seek to include participants
>from all over the world who are respected leaders in the field relevant to
>the topic before the working group. Participants can come from industry,
>government, policy groups, academia and the user community. Each working
>group would have a written terms of reference explicitly stating its
>mandate, goals, start date, end date and other pertinent information.
>
>There are four working groups to date:
> 1. certificate authority service provider subscriber
>authentification subscriber business practices and policies
> 2. content blocking business procedures and practices
> 3. information clearinghouse Internet law and policy
> 4. domain name assignment and registry administration issues
>
>Part of this proof-of-concept phase is finding out whether our assumptions
>and initial ideas are strong and how they should be improved. Also, there
>is a need to reach out to established organizations and to work
>cooperatively so as to avoid duplication and redundancy on issues of mutual
>interest. Some have asked why get involved with the ILPF when my ISP or
>NIC association is active on similar issues. ISPs are only one of many
>segments of the industries involved in the Internet (e.g., telcos,
>hardware, content producers, OSPs, search engine cos, directory services,
>CASPs, Registry Services). New organizations usually cause some to be
>concerned about turf. This is a headache I hope ILPF can avoid by finding
>effective ways to collaborate and work together cooperatively.
>
>
>Personal Observations / Closing Thoughts.
>
>The volunteers of the ILPF have reached out to many. It has been
>distressing at times during the past two weeks to see some of these parties
>assail the ILPF or those speaking on its behalf. Admittedly much of the
>ILPF's organizational activities have not been memorialized widely.
>Openness is an area of improvement for the ILPF. Hopefully that will
>become a reality as the ILPF utilizes a formal administrative contact and
>support resource to help shepherd the volunteers through the remainder of
>the organizational phase. However, it is personally upsetting to view
>comments by individuals that attack as an outsider when they have been
>asked to become involved numerous time before.
>
>Bottom line: If the ILPF organizing phase can produce some work product
>that is acceptable to interested parties and is found to be useful, it can
>then move forward into a more formal level of activity, sponsoring a few
>working groups a year. If people learn more about what the Internet means
>to others around the world and what it can do as a result of the ILPF's
>activity and existence, then I think the ILPF has done some good.
>
>Peter Harter
>
>
>
>
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10224;
19 Jul 96 12:42 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10218;
19 Jul 96 12:42 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10517;
19 Jul 96 12:42 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <PAA16084 at pad-thai.cam.ov.com>; Fri, 19 Jul 1996 15:46:12 GMT
Received: from BITSY.MIT.EDU by MIT.EDU with SMTP
id AA00212; Fri, 19 Jul 96 11:46:10 EDT
Received: from clbull.frcl.bull.fr by bitsy.MIT.EDU with SMTP
id AA18137; Fri, 19 Jul 96 11:46:03 EDT
Received: from emsc.frcl.bull.fr (emsc.frcl.bull.fr [129.182.42.100]) by clbull.frcl.bull.fr (8.7.5/8.7.3) with SMTP id RAA18924; Fri, 19 Jul 1996 17:44:49 +0200
Received: by emsc.frcl.bull.fr (AIX 3.2/UCB 5.64/4.03)
id AA28513; Fri, 19 Jul 1996 16:38:42 +0100
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Message-Id: <9607191538.AA28513 at emsc.frcl.bull.fr>
Subject: Re: Regarding sneg-mech
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Date: Fri, 19 Jul 1996 16:38:41 +0100 (NFT)
Cc: sommerfeld at apollo.hp.com, rsalz at osf.org, marc at mit.edu,
cat-ietf at bitsy.mit.edu
In-Reply-To: <9607182028.AA25082 at dcl.MIT.EDU> from "Theodore Y. Ts'o" at Jul 18, 96 04:28:49 pm
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 2.4
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
> I'll propose for snego what he proposed for SSL:
This is a *BIG* difference between SSL and snego. SSL is using some
algorithms which are well defined, so it can make sense to use some
of them in the negotiation phase.
On the other side snego allows to use any kind of mechanism using
any kind of algorithm.
We must not loose this flexibility. There are been various exchanges
to allow to appreciate the vulnerabilities of snego which do not mandate
any crypto.
We should also have in mind the meaning of the "s" within the acronym
"snego". It means "Simple", neither "Sophisticated" nor "Secure".
> The `snego' exchange should (logically) be, in sequence:
>
> - cleartext negotiation to find common mechanism
> - crypto negotiation to establish mechanism
> - exchange of MAC of negotiation parameters
>
> During the third stage, the peers can each verify that the other
> received the "offer" which they sent; if they didn't, the negotiation
> can be terminated.
>
> This is also exactly what I ended up using to protect the telnet
> authentication option, except that I used the optimization which Bill
> proposed:
>
> - if the mechanism allows is (e.g., kerberos will allow it), you can
> piggyback the MAC of the parameters along with the initial token.
>
> It's a pretty natural and obvious way of doing things, as we can see as
> it apparently has been independently re-invented a number of times
> already!
If we could have a standard way to piggy back the negotiation token and
the first init token, I would say that this would be valuable.
At this time, I have not think about the implications but my
feeling is that we would be loosing some functionality: today the code
cannot distinguish whether it is doing a negotiation or a multiple
authentication exchange without negotiation ... and this is fine.
Denis
--
============================================================================
Denis Pinkas E-mail : D.Pinkas at frcl.bull.fr
Bull S.A.
Rue Jean Jaures B.P. 68 Phone : (33-1) 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : (33-1) 30 80 33 21
============================================================================
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13013;
19 Jul 96 16:19 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa14839; 19 Jul 96 16:19 EDT
Received: from ietf.org by ietf.org id aa12339; 19 Jul 96 16:19 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa12040;
19 Jul 96 15:49 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12565;
19 Jul 96 15:49 EDT
Received: from [24.0.8.9] by CNRI.Reston.VA.US id aa14259; 19 Jul 96 15:49 EDT
Received: from aloha.home.net (aloha.eos.home.net [24.0.8.87])
by poptart.home.net (Netscape Mail Server v1.1) with SMTP
id AAA17768; Fri, 19 Jul 1996 12:47:37 -0700
X-Sender: pvm at poptart.home.net
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: "C.Joe Pasquariello" <pasquarc at ncr.disa.mil>
Sender:ietf-request at ietf.org
From: Paul Mockapetris <pvm at home.net>
Subject: Re: Has the IETF outlived its Usefulness? (this is what I
Cc: IETF at CNRI.Reston.VA.US
Date: Fri, 19 Jul 1996 12:47:37 -0700
Message-ID: <19960719194734.AAA17768 at aloha.home.net>
Source-Info: From (or Sender) name not authenticated.
At 11:58 AM 7/18/96 EST, C.Joe Pasquariello wrote:
> PAUL -
>
> I believe that your characterization below of the ISOC 'absorption' of
> the IETF is considerably overstated, and possibly counterproductive to
> the recently completed good work of the Poised Group.
The IETF lived before the ISOC, was independent under RFC 1602, and is no
longer.
For better or worse, its over, but it is what happened. Moreover, most
people who go to IETFs just don't care that much. I think I have joined
them. You should too.
paul
@Home main: 415-944-7200
385 Ravendale direct: 415-944-7221
Mountain View, CA 94043
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08940;
20 Jul 96 19:21 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa12267; 20 Jul 96 19:21 EDT
Received: from ietf.org by ietf.org id aa26558; 20 Jul 96 19:21 EDT
Received: from pinky.junction.net by ietf.org id aa26500; 20 Jul 96 19:13 EDT
Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id PAA07721; Sat, 20 Jul 1996 15:23:58 -0700
Received: from localhost (michael at localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id QAA05802; Sat, 20 Jul 1996 16:08:34 -0700
Date: Sat, 20 Jul 1996 16:08:33 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Michael Dillon <michael at memra.com>
To: "newdom at iiia.org" <newdom at iiia.org>
cc: ietf at ietf.org
Subject: IETF WG charter not needed for NEWDOM
In-Reply-To: <01BB7637.F468AC40 at jfbb.atmnet.net>
Message-ID: <Pine.BSI.3.93.960720154725.26371O-100000 at sidhe.memra.com>
Organization: Memra Software Inc. - Internet consulting
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sat, 20 Jul 1996, Jim Browning wrote:
> and it *does* include non-technical issues. Why this desire to segregate
> the efforts of IANA and this WG?? Are you saying that IANA should operate
> without the input of the IETF community?
This discussion has been taking place here on newdom since last September
and the IETF community has been informed of that fact as well as other
communities of Internet users who would be impacted by IANA's plan.
There is simply no need to create a WG to deal with issues that have
already been dealt with in this forum. The only reason to do so would be
political posturing and turf wars like some of the stuff that has happened
between IETF and W3C. In addition to ILPF, IETF, W3C and the X consortium,
there is no good reason why we cannot fulfill the open WG style procedures
right here in NEWDOM.
> The efforts need to be integrated.
NEWDOM is as good a place to integrate this as any. If this whole effort
ends up getting entangled in IETF bureaucracy then the Alternic and
Denninger will move ahead all the more quickly with their plans and will
have all the more ammunition to use in convincing network administrators
to use their new system of root nameservers.
Quite frankly, IETF has no control whatsoever over this situation. The
only party that is in a position to influence the situation is IANA. So
far they have taken great pains to bounce ideas off a lot of different
parties and to craft a plan that can reach consensus. It's not perfect yet
but it has also not showed any signs of being hopelessly stalled or headed
off into left field.
If IETF people want to be involved in this discussion they have been
notified several times that it is happening here in NEWDOM. Subscription
info and list archives are at http://www.iiia.org/lists/newdom/
Background info is available at http://www.memra.com/ndbg.html
And this is yet another notice on the IETF list to tell folks where to
find this. If any IETF'ers want to jump into the discussion, a good place
to start is with this message
http://www.iiia.org/lists/newdom/current/0518.html
which contains an intermediate version of Postel's draft between the
second published draft in the IETF archives and the third revision which
we expect to see soon. If you scan through the messages after this one you
will get a rough idea of where the discussions are at.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael at memra.com
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08983;
20 Jul 96 19:38 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa12408; 20 Jul 96 19:38 EDT
Received: from ietf.org by ietf.org id aa26719; 20 Jul 96 19:38 EDT
Received: from core.atmnet.net by ietf.org id aa26674; 20 Jul 96 19:36 EDT
Received: from jfbb.atmnet.net (jfbb.atmnet.net [207.67.252.138]) by core.atmnet.net (8.7.5/8.6.9) with SMTP id QAA23219; Sat, 20 Jul 1996 16:35:50 -0700 (PDT)
Received: by jfbb.atmnet.net with Microsoft Mail
id <01BB7659.B0D470A0 at jfbb.atmnet.net>; Sat, 20 Jul 1996 16:37:07 -0700
Message-ID: <01BB7659.B0D470A0 at jfbb.atmnet.net>
Sender:ietf-request at ietf.org
From: Jim Browning <jfbb at atmnet.net>
To: 'Michael Dillon' <michael at memra.com>
Cc: "ietf at ietf.org" <ietf at ietf.org>, "newdom at iiia.org" <newdom at iiia.org>
Subject: RE: IETF WG charter not needed for NEWDOM
Date: Sat, 20 Jul 1996 16:37:05 -0700
Encoding: 30 TEXT
Source-Info: From (or Sender) name not authenticated.
>From: Michael Dillon[SMTP:michael at memra.com]
>Sent: Saturday, July 20, 1996 9:09 AM
>
>On Sat, 20 Jul 1996, Jim Browning wrote:
>
>> and it *does* include non-technical issues. Why this desire to
segregate
>> the efforts of IANA and this WG?? Are you saying that IANA should
operate
>> without the input of the IETF community?
>
>This discussion has been taking place here on newdom since last September
>and the IETF community has been informed of that fact as well as other
>communities of Internet users who would be impacted by IANA's plan.
>
>There is simply no need to create a WG to deal with issues that have
>already been dealt with in this forum. The only reason to do so would be
>political posturing and turf wars like some of the stuff that has happened
>between IETF and W3C. In addition to ILPF, IETF, W3C and the X consortium,
>there is no good reason why we cannot fulfill the open WG style procedures
>right here in NEWDOM.
I appreciate your comments. I am not suggesting that a *different* group
be formed, only that this one focus on refining IANA's draft (preferably
with WG recognition), which I suspect will at some point be submitted to
the IESG with a request to give it RFC/BCP status.
--
Jim Browning
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09151;
20 Jul 96 20:32 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa12942; 20 Jul 96 20:32 EDT
Received: from ietf.org by ietf.org id aa27195; 20 Jul 96 20:32 EDT
Received: from alex.mrls.com by ietf.org id aa27128; 20 Jul 96 20:29 EDT
Received: (from ekashp at localhost) by alex.mrls.com (8.6.12/8.6.6) id RAA03167; Sat, 20 Jul 1996 17:28:32 -0700
Date: Sat, 20 Jul 1996 17:28:32 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Eugene Kashpureff <ekashp at mrls.com>
To: Jim Browning <jfbb at atmnet.net>
cc: 'Michael Dillon' <michael at memra.com>, "ietf at ietf.org" <ietf at ietf.org>,
"newdom at iiia.org" <newdom at iiia.org>
Subject: RE: IETF WG charter needed for NEWDOM
In-Reply-To: <01BB7659.B0D470A0 at jfbb.atmnet.net>
Message-ID: <Pine.LNX.3.91.960720172531.3163A-100000 at alex.mrls.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sat, 20 Jul 1996, Jim Browning wrote:
> >there is no good reason why we cannot fulfill the open WG style procedures
> >right here in NEWDOM.
> be formed, only that this one focus on refining IANA's draft (preferably
> with WG recognition), which I suspect will at some point be submitted to
> the IESG with a request to give it RFC/BCP status.
All in favour say Aye !
A Y E !
> Jim Browning
At your name service,
Eugene Kashpureff, ALTERNIC.NET
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09231;
20 Jul 96 20:42 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09227;
20 Jul 96 20:42 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13051;
20 Jul 96 20:42 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09219;
20 Jul 96 20:42 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09215;
20 Jul 96 20:42 EDT
Received: from core.atmnet.net by CNRI.Reston.VA.US id aa13043;
20 Jul 96 20:42 EDT
Received: from jfbb.atmnet.net (jfbb.atmnet.net [207.67.252.138]) by core.atmnet.net (8.7.5/8.6.9) with SMTP id RAA23692; Sat, 20 Jul 1996 17:41:33 -0700 (PDT)
Received: by jfbb.atmnet.net with Microsoft Mail
id <01BB7662.DCA516E0 at jfbb.atmnet.net>; Sat, 20 Jul 1996 17:42:46 -0700
Message-ID: <01BB7662.DCA516E0 at jfbb.atmnet.net>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jim Browning <jfbb at atmnet.net>
To: "'davidc at APNIC.NET'" <davidc at apnic.net>, "'dfk at RIPE.NET'" <dfk at ripe.net>,
"'kimh at internic.net'" <kimh at internic.net>,
"'markk at internic.net'" <markk at internic.net>,
"'Postel at ISI.EDU'" <Postel at isi.edu>
Cc: 'CIDRD List' <cidrd at iepg.org>, 'IESG' <iesg at CNRI.Reston.VA.US>,
'IETF' <ietf at CNRI.Reston.VA.US>
Subject: draft-hubbard-registry-guidelines-03.txt
Date: Sat, 20 Jul 1996 17:42:44 -0700
Encoding: 216 TEXT
As reflected in the minutes of the CIDRD WG meeting in Montreal, the IESG
has requested additional comments on the referenced draft. To the extent
that this message reiterates comments I made about the earlier draft, I
apologize for the redundancies, however if they are included here, it is
because my earlier comments still apply:
> 1. Introduction
>
>
> Internet address space is distributed according to the following
> three goals:
>
> 1) Conservation: Fair distribution of globally unique Internet address
> space according to the operational needs of the end-users and Internet
> Service Providers operating networks using this address space.
> Prevention of stockpiling in order to maximize the lifetime of the
> Internet address space.
The reference to "Fair distribution" should be removed from the
Conservation paragraph because it is out of context. Fair Distribution and
Conservation are both important goals, but they are not the *same* goals.
In fact, the two often conflict. I recommend that they be split into
separate goals by adding the following:
4) Fair Distribution: Allocation of IP addresses according to the
operational needs of end-users, fairly and objectively determined.
> It is in the interest of the Internet community as a whole that the
> above goals be pursued. However it should be noted that
> "Conservation" and "Routability" are often conflicting goals. All
> the above goals may sometimes be in conflict with the interests of
> individual end-users or Internet service providers. Careful analysis
> and judgement is necessary in each individual case to find an
> appropriate compromise.
Compromise is not an appropriate goal. It presumes that there will be a
negotiation, and that the end result will be the allocation of an address
block smaller than requested, but larger than initially offered. As
opposed to 'judgment and compromise'', the goal should be "the consistent
application of objective criteria", which will result in a correct and
supportable decision. Compromises, while they give something to each party
in a negotiation, rarely result in the best decision.
> IANA
>
> The Internet Assigned Numbers Authority has authority over all number
> spaces used in the Internet. This includes Internet Address Space. IANA
> allocates parts of the Internet address space to regional IRs according
> to its established needs.
The source of IANA's authority should be referenced:
<draft-ietf-poised95-ietf-orgs-03.txt>, or another more definitive
reference if there is one.
> Regional IRs
>
> Regional IRs are established under the authority of the IANA. This
> requires consensus within the Internet community of the region. A con-
> sensus of Internet Service Providers in that region may be necessary to
> fulfill that role.
The process for establishing these IRs should be clearly defined, as should
the mechanisms for evaluating whether the distribution goals outlined in
this draft are being met.
> The specific duties of the regional IRs include coordination and
> representation of all local IRs in its respective regions.
The duties of the IRs should include meeting the distribution objectives
and ensuring that local IRs meet them as well.
> Local IRs
>
> Local IRs are established under the authority of the regional IR and
> IANA. These local registries have the same role and responsibility as
> the regional registries within its designated geographical areas. These
> areas are usually of national dimensions.
Just as with the IRs, The process for establishing Local IRs should be
clearly defined, as should the mechanisms for evaluating whether the
distribution goals outlined in this draft are being met at the local level.
>
> 2. Allocation Framework
>
> 2.1 Guidelines for Internet Service Providers (ISPs)
[snip]
> ISPs who exchange routing information with other ISPs at multiple loca-
> tions and operate without default routing may request space directly
> from the regional registry in its geographical area.
Many multi-homed ISPs, with peering agreements in place, choose to maintain
a default route as well. I see no reason why this draft should prohibit
such an ISP from obtaining a direct allocation of addresses when other
factors indicate that it is appropriate.
[snip]
> To facilitate hierarchical addressing, implemented using Classless
> Inter-Domain Routing (CIDR), all other ISPs should request address space
> directly from its upstream provider. ISPs only request address space
> directly from regional registries if their immediate requirement, when
> satisfied with a contiguous block allocation, has a reasonable probabil-
> ity of being routable on the Internet, and they meet one or more of the
> following conditions.
>
> a) the ISP is directly connected to a major routing exchange
> (for purposes of this document, a major routing exchange
> is defined as a neutral layer 2 exchange point connecting
> four or more unrelated ISPs.)
The issue of physical connectivity should not be a concern of this draft.
Many people believe that the future will see an increased reliance on
regional exchanges (which may or may not fit the above definition) and
private exchange/peering agreements which do not occur at an exchange
point. Several major NSPs have begun taking the private exchange (between
only two providers) approach in order to reduce congestion at the NAPs.
There is no reason these efforts should be discouraged through IP
allocation policy. The issue is whether there is a valid need for
addresses, and this has little to do with where networks are exchanging
traffic.
> b) the ISP is multi-homed, that is, it has more than one
> simultaneous connection to the global Internet and no
> connection is favored over the other
I don't understand why favoring one connection over another should be a
factor. I also fail to see how this can be objectively determined. Does
this mean that if an ISP is multi-homed with two connections of the same
speed to two different NSPs, but she pads her AS path for one of them so
route traffic is carried on a preferred (for whatever reason) path, that
she can not obtain a direct allocation of addresses? I think this approach
prevents the application of objective criteria.
> The following are the IP allocation guidelines for ISPs:
[snip]
> 4. IP addresses are allocated to ISPs using a slow-start
> procedure. New ISPs will receive a minimal amount based
> on immediate requirement. Thereafter, allocated blocks may be
> increased based on utilization verification supplied to the
> regional registry. The parent registries are responsible for
> determining appropriate initial and subsequent allocations.
> Additional address allocations will provide enough address space
> to enable the ISP to assign addresses for three months
> without requesting additional address space from its parent
> registry. Please note that projected customer base has little
> impact on the address allocations made by the parent registries.
> Initial allocation will not be based on any current or future
> routing restrictions but on demonstrated requirements.
There is an apparent conflict between this paragraph and later (Section 3)
paragraphs which reference a one-year period which will be taken into
account, and that there needs to be only 50% utilization in the first year.
[snip]
> 6. Regional registries may set a maximum limit on assignment sizes
> such that a second opinion of the regional registry is required.
This appears to be discussing the internal mechanics of a registry, but
only with respect to one detail. If the draft is going to define *how* a
registry meets the distribution goals, then there are a whole host of other
details that need to be specified. I suggest either deleting this
paragraph, or restating it so that it addresses obtaining additional
opinions from regional registries parent registry.
[snip]
> 3. Assignment Framework
>
> An assignment is the delegation of authority over a block of IP
> addresses to an end enterprise. The end enterprise will use addresses
> from an assignment internally only; it will not sub-delegate those
> addresses. This section discusses some of the issues involved in
> assignments and the framework behind the assignment of addresses.
>
> In order for the Internet to scale using existing technologies, use of
> regional registry services should be limited to the assignment of IP
> addresses for organizations meeting one or more of the following condi-
> tions:
>
> a) the organization has no intention of connecting to
> the Internet-either now or in the future-but it still
> requires a globally unique IP address. The organization
> should consider using reserved addresses from RFC1918.
> If it is determined this is not possible, they can be
> issued unique (if not Internet routable) IP addresses.
>
> b) the organization is multi-homed with no favored connection.
>
> c) the organization's actual requirement for IP space is
> very large, for example, the network prefix required to
> cover the request is of length /18 or shorter.
If I am reading section 3 correctly (the wording could be clearer), it is
differentiating between end users who want to obtain addresses from a
registry, and ISPs who want to obtain addresses from a registry. Why the
distinction? Why should an end user with a large (/18 or shorter)
requirement be allowed to obtain addresses from a registry, when an ISP
with a similar size requirement must also meet other criteria (NAP
connection, multi-homing, etc.). If there are to be different criteria
based upon whether a requester will be assigning addresses to other
entities, I would think the criteria should be less confining for the ISP,
as the size of her address space is more likely to increase in the future,
and she is more likely to end up with a NAP connection and/or be
multi-homed.
This revision is much improved, although I believe there are substantive
issues (e.g., how registries are established) which must still be addresses
<NPI>. I appreciate the effort put forth by its authors, and the
opportunity to provide additional comments.
--
Jim Browning <jfbb at ATMnet.net>
619/643-1802 Fax 619/643-1801
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09890;
20 Jul 96 22:26 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa14094; 20 Jul 96 22:26 EDT
Received: from ietf.org by ietf.org id aa28745; 20 Jul 96 22:25 EDT
Received: from pinky.junction.net by ietf.org id aa28137; 20 Jul 96 22:23 EDT
Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id SAA09947; Sat, 20 Jul 1996 18:34:01 -0700
Received: from localhost (michael at localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id TAA07192; Sat, 20 Jul 1996 19:18:37 -0700
Date: Sat, 20 Jul 1996 19:18:36 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Michael Dillon <michael at memra.com>
To: "newdom at iiia.org" <newdom at iiia.org>
cc: "ietf at ietf.org" <ietf at ietf.org>
Subject: RE: IETF WG charter not needed for NEWDOM
In-Reply-To: <01BB7659.B0D470A0 at jfbb.atmnet.net>
Message-ID: <Pine.BSI.3.93.960720191552.26371R-100000 at sidhe.memra.com>
Organization: Memra Software Inc. - Internet consulting
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sat, 20 Jul 1996, Jim Browning wrote:
> I appreciate your comments. I am not suggesting that a *different* group
> be formed, only that this one focus on refining IANA's draft (preferably
> with WG recognition), which I suspect will at some point be submitted to
> the IESG with a request to give it RFC/BCP status.
OK. If the IETF would retroactively recognize NEWDOM as a WG I have no
problem with writing up a charter based on what we have done here. But it
is not at all clear just what goals the people working on a charter have
in mind or whether IETF would even consider granting such retroactive WG
status.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael at memra.com
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05548;
21 Jul 96 0:37 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa01296; 21 Jul 96 0:37 EDT
Received: from ietf.org by ietf.org id aa05716; 21 Jul 96 0:37 EDT
Received: from stilton.cisco.com by ietf.org id aa05643; 21 Jul 96 0:34 EDT
Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id VAA06797; Sat, 20 Jul 1996 21:33:01 -0700
X-Sender: fred at stilton.cisco.com
Message-Id: <v02140b00ae175da3577b at [171.69.128.114]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 20 Jul 1996 21:36:36 -0700
To: Michael Dillon <michael at memra.com>
Sender:ietf-request at ietf.org
From: Fred Baker <fred at cisco.com>
Subject: RE: IETF WG charter not needed for NEWDOM
Cc: "newdom at iiia.org" <newdom at iiia.org>, "ietf at ietf.org" <ietf at ietf.org>
Source-Info: From (or Sender) name not authenticated.
At 7:18 PM 7/20/96, Michael Dillon said:
> OK. If the IETF would retroactively recognize NEWDOM as a WG I have no
> problem with writing up a charter based on what we have done here. But it
> is not at all clear just what goals the people working on a charter have
> in mind or whether IETF would even consider granting such retroactive WG
> status.
If, as we have requested, the NEWDOM folks would write up a charter and
send it to iesg at ietf.org (yes, I know that one has been posted to the
NEWDOM list, in among the recipes, discussions of the war of 1812, and deep
soul-searching about the domains .NATO, .TV, and .HOME - but it hasn't been
agreed to or forwarded to the IESG for consideration, and does not at this
point andswer the necessary questions) so that we can determine what goals
and time lines you have, we might be willing to grant you a working group.
If you will explain to us the problem you want to solve and tell us why
your solution is the best solution, we might even decide that it is the
right solution, one we want to bless.
The Operations and Applications Area Directors have put specific questions
to the working group that need to be addressed in the charter and in the
outcome documentation. These relate to the advisability of using a flat
name space at the top level in a world where addressing hierarchy is
necessary to maintain sanity, and the likelihood that an international
entity would have to register with multiple name servers (perhaps all or
most, in the case of a conglomerate corporation) in order to maintain its
trademarks in marketplaces in which it does business. I expect to see those
specifically addressed.
> NEWDOM is as good a place to integrate this as any. If this whole effort
> ends up getting entangled in IETF bureaucracy then the Alternic and
> Denninger will move ahead all the more quickly with their plans and will
> have all the more ammunition to use in convincing network administrators
> to use their new system of root name servers.
One thing I really don't understand is the amount of "nose thumbing" that
is going on here in place of communication. You are not entangled in
bureaucracy. Rick Wesson and others have asked us to charter a working
group. We don't do so without a charter, and we have asked for a charter. I
could easily imagine the charter specifying the NEWDOM list - I'm not sure
why it would not.
The ball is in your court.
Fred Baker
IETF Chair
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I don't suffer from insanity. I enjoy every minute of it.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05933;
21 Jul 96 2:33 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa02459; 21 Jul 96 2:33 EDT
Received: from ietf.org by ietf.org id aa06794; 21 Jul 96 2:33 EDT
Received: from pinky.junction.net by ietf.org id aa06702; 21 Jul 96 2:30 EDT
Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id WAA12829; Sat, 20 Jul 1996 22:41:22 -0700
Received: from localhost (michael at localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id XAA09090; Sat, 20 Jul 1996 23:25:59 -0700
Date: Sat, 20 Jul 1996 23:25:57 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Michael Dillon <michael at memra.com>
To: "newdom at iiia.org" <newdom at iiia.org>
cc: "ietf at ietf.org" <ietf at ietf.org>
Subject: RE: IETF WG charter not needed for NEWDOM
In-Reply-To: <v02140b00ae175da3577b at [171.69.128.114]>
Message-ID: <Pine.BSI.3.93.960720230243.26371X-100000 at sidhe.memra.com>
Organization: Memra Software Inc. - Internet consulting
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sat, 20 Jul 1996, Fred Baker wrote:
> The Operations and Applications Area Directors have put specific questions
> to the working group that need to be addressed in the charter and in the
> outcome documentation.
I don't recall seeing these but, as you point out, the discussion has
taken a number of different tacks and I may have missed it.
> These relate to the advisability of using a flat
> name space at the top level in a world where addressing hierarchy is
> necessary to maintain sanity,
The current proposal that is being worked on maintains an addressing
hierarchy and only suggests a modest increase in the number of TLD's
which would no more than double the number in the first year. The actual
creation of a TLD requires an application procedure that requires
applicants to write a specific detailled plan for operating the new TLD's
that they are allocated. This application is even more detailled than the
average business plan so that applying for a TLD is not a trivial process.
There is no plan to open up the TLD namespace to all comers and after the
first year the number of new TLD's created per year may be kept very low
unless experience dictates that it should be otherwise.
> and the likelihood that an international
> entity would have to register with multiple name servers (perhaps all or
> most, in the case of a conglomerate corporation) in order to maintain its
> trademarks in marketplaces in which it does business.
I don't think this is really relevant since it has no negative effects on
the DNS system. However, registries which operate new TLD's are given a
broad latitude in how they operate and the policies they set for entities
which register in those new TLD's. It is expected that some of these TLD's
will be either close to such international entities or perhaps
unattractive to those entities. At least one potential registry has
announced that they will only allocate second level domains to themself
and will instead register third level domains to the public. If this
strategy works out it will make much better use of the hierarchy and
if the domains registered at the 3rd level see widespread public use it
may well encourage other 3rd level registries.
> > NEWDOM is as good a place to integrate this as any. If this whole effort
> > ends up getting entangled in IETF bureaucracy then the Alternic and
> > Denninger will move ahead all the more quickly with their plans and will
> > have all the more ammunition to use in convincing network administrators
> > to use their new system of root name servers.
>
> One thing I really don't understand is the amount of "nose thumbing" that
> is going on here in place of communication. You are not entangled in
> bureaucracy.
I didn't say that we were entangled. I said "if" meaning that it might
possibly happen and we should strive to avoid it. If I interpret you
correctly then you have addressed that issue. Correct me if I am wrong in
assuming that IESG would be willing to give the NEWDOM group WG status
without requiring us to start from square one if we can write an adequate
charter. This would mean that there are no barriers to having a charter
accepted and the first RFC accepted within a month from now.
Now all we ned to do is get a proper charter written.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael at memra.com
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06326;
21 Jul 96 3:50 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa03287; 21 Jul 96 3:50 EDT
Received: from ietf.org by ietf.org id aa07555; 21 Jul 96 3:50 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa07487; 21 Jul 96 3:47 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06315;
21 Jul 96 3:47 EDT
Received: from gw.home.vix.com by CNRI.Reston.VA.US id aa03262;
21 Jul 96 3:47 EDT
Received: by gw.home.vix.com id AAA13423; Sun, 21 Jul 1996 00:47:50 -0700 (PDT)
Date: Sun, 21 Jul 1996 00:47:50 -0700 (PDT)
X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us
To: ietf at CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: Paul A Vixie <paul at vix.com>
Subject: Re: Last Call: TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms
Organization: Vixie Enterprises
Message-ID: <VIXIE.96Jul21004748 at wisdom.vix.com>
References: <96Jul16.002816pdt.119177-24507+8 at cesium.clock.org>
NNTP-Posting-Host: wisdom.home.vix.com
In-reply-to: smd at cesium.clock.org's message of 16 Jul 1996 04:54:20 -0700
Source-Info: From (or Sender) name not authenticated.
> Let's pretend that this gets turned on by default by
> most network operators in the future.
This sounds like the httpd hack I did a while back that rejects concurrent
connections from the same host, thus defeating Netscape's odd habit of opening
lots of simultaneous HTTP connections to the same place at the same time "to
get better service."
And it sounds like the INN hack I expect to become standard soon, which will
do the same thing in the NNTP space.
In other words, it sounds pretty good to me.
--
Paul Vixie
La Honda, CA"Illegitimibus non carborundum."
<paul at vix.com>
pacbell!vixie!paul
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06560;
21 Jul 96 4:35 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06556;
21 Jul 96 4:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03774;
21 Jul 96 4:35 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06548;
21 Jul 96 4:35 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06544;
21 Jul 96 4:35 EDT
Received: from dxmint.cern.ch by CNRI.Reston.VA.US id aa03769;
21 Jul 96 4:35 EDT
Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch
with SMTP id KAA19529; Sun, 21 Jul 1996 10:35:05 +0200 (MET DST)
Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM)
id AA13047; Sun, 21 Jul 1996 10:35:04 +0200
Message-Id: <9607210835.AA13047 at dxcoms.cern.ch>
Subject: Re: draft-hubbard-registry-guidelines-03.txt
To: Jim Browning <jfbb at atmnet.net>
Date: Sun, 21 Jul 1996 10:35:04 +0200 (MET DST)
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Brian Carpenter CERN-CN <brian at dxcoms.cern.ch>
Cc: davidc at apnic.net, dfk at ripe.net, kimh at internic.net, markk at internic.net,
Postel at isi.edu, cidrd at iepg.org, iesg at CNRI.Reston.VA.US,
ietf at CNRI.Reston.VA.US
In-Reply-To: <01BB7662.DCA516E0 at jfbb.atmnet.net> from "Jim Browning" at Jul 20, 96 05:42:44 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Jim,
>--------- Text sent by Jim Browning follows:
>
...
> > IANA
> >
> > The Internet Assigned Numbers Authority has authority over all number
> > spaces used in the Internet. This includes Internet Address Space. IANA
> > allocates parts of the Internet address space to regional IRs according
> > to its established needs.
>
> The source of IANA's authority should be referenced:
> <draft-ietf-poised95-ietf-orgs-03.txt>, or another more definitive
> reference if there is one.
see RFC 1601
Brian Carpenter
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08666;
21 Jul 96 12:37 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa08741; 21 Jul 96 12:37 EDT
Received: from ietf.org by ietf.org id aa12931; 21 Jul 96 12:37 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa12855;
21 Jul 96 12:33 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08650;
21 Jul 96 12:33 EDT
Received: from ng.netgate.net by CNRI.Reston.VA.US id aa08694;
21 Jul 96 12:33 EDT
Received: from [205.214.160.116] (d28.netgate.net [205.214.160.60]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id JAA20969; Sun, 21 Jul 1996 09:40:18 -0700 (PDT)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v03007806ae18058d6bd2 at [205.214.160.116]>
In-Reply-To: <VIXIE.96Jul21004748 at wisdom.vix.com>
References: smd at cesium.clock.org's message of 16 Jul 1996 04:54:20 -0700
<96Jul16.002816pdt.119177-24507+8 at cesium.clock.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Sun, 21 Jul 1996 09:05:22 -0700
To: Paul A Vixie <paul at vix.com>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re: Last Call: TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms
Cc: ietf at CNRI.Reston.VA.US
Source-Info: From (or Sender) name not authenticated.
At 12:47 AM -0700 7/21/96, Paul A Vixie wrote:
>This sounds like the httpd hack I did a while back that rejects concurrent
>connections from the same host, thus defeating Netscape's odd habit of opening
>lots of simultaneous HTTP connections to the same place at the same time "to
>get better service."
Paul, just to make sure the implications are clear:
So, if two people are coming from the same host and going to the
same host via http, the second one loses?
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08829;
21 Jul 96 12:51 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa08927; 21 Jul 96 12:51 EDT
Received: from ietf.org by ietf.org id aa13250; 21 Jul 96 12:51 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa13199;
21 Jul 96 12:50 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08810;
21 Jul 96 12:50 EDT
Received: from gw.home.vix.com by CNRI.Reston.VA.US id aa08914;
21 Jul 96 12:50 EDT
Received: by gw.home.vix.com id JAA13084; Sun, 21 Jul 1996 09:50:20 -0700 (PDT)
X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us
Received: by wisdom.home.vix.com id AA15906; Sun, 21 Jul 1996 09:50:20 -0700
Message-Id: <9607211650.AA15906 at wisdom.home.vix.com>
To: Dave Crocker <dcrocker at brandenburg.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms
In-Reply-To: Your message of "Sun, 21 Jul 1996 09:05:22 PDT."
<v03007806ae18058d6bd2 at [205.214.160.116]>
Date: Sun, 21 Jul 1996 09:50:20 -0700
Sender:ietf-request at ietf.org
From: Paul A Vixie <paul at vix.com>
Source-Info: From (or Sender) name not authenticated.
>So, if two people are coming from the same host and going to the
> same host via http, the second one loses?
Rats. I knew someone was going to catch that. No. I did it the way I
said, and it did what you said, so I had to back out and think about it
some more.
What I ended up with was a 2 dimensional listener queue, such that instead
of a FIFO of "SYN received" elements, I have a FIFO of "a SYN has been
received from this host" lists, where each list is limited to a small number
(2, 3, 4, and 5 all work well) of elements.
I thought (and still think) that this was crazy, but the alternative was to
let a single host on a ratty link suck down a large percentage of my listen
queue. SGI and DEC and others just made the listen queue arbitrarily large,
but I don't think that addresses the real problem. Netscape users ought to
suffer unless they set their connection quota down to 2 or ideally 1.
The "right" fix is to move this quota out of the listen queue and into some
kind of host-wise table. Then we could keep track of congestion and window
size in a way that was shared by all open TCP connections to a certain other
host, and we could do it with a small amount of persistence so that we would
not have to rediscover the right window size for every little GIF on someone's
home page. I regret that I will never understand TCP well enough to do the
right thing. But the hack described above has wonderful results.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09365;
21 Jul 96 14:28 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa09967; 21 Jul 96 14:28 EDT
Received: from ietf.org by ietf.org id aa14099; 21 Jul 96 14:28 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa14033;
21 Jul 96 14:25 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09350;
21 Jul 96 14:25 EDT
Received: from ng.netgate.net by CNRI.Reston.VA.US id aa09940;
21 Jul 96 14:25 EDT
Received: from [205.214.160.60] (d28.netgate.net [205.214.160.60]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id LAA26506; Sun, 21 Jul 1996 11:32:20 -0700 (PDT)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v03007800ae1823d35366 at [205.214.160.116]>
In-Reply-To: <9607211650.AA15906 at wisdom.home.vix.com>
References: Your message of "Sun, 21 Jul 1996 09:05:22 PDT."
<v03007806ae18058d6bd2 at [205.214.160.116]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Sun, 21 Jul 1996 11:25:00 -0700
To: Paul A Vixie <paul at vix.com>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re: Last Call: TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms
Cc: ietf at CNRI.Reston.VA.US
Source-Info: From (or Sender) name not authenticated.
At 9:50 AM -0700 7/21/96, Paul A Vixie wrote:
>>So, if two people are coming from the same host and going to the
>> same host via http, the second one loses?
>
>Rats. I knew someone was going to catch that. No. I did it the way I
>said, and it did what you said, so I had to back out and think about it
>some more.
I sent my original query only thinking of the usual, shared-host
timesharing system scenarios (aol, compuserve, netcom, ...). A little bit
later, it occurred to me that this unfortunately includes a large class of
firewall gateways...
>What I ended up with was a 2 dimensional listener queue, such that instead
So, it's n connections from a given host, rather than 1. Sounds
like a reasonable, alternate position given the nature of the current
problem. It will still hurt shared-host users, given that they get to duke
it out for the n connections and these things don't automatically result in
fair sharing, but what the heck. I doubt you can do better within current
limitations.
>The "right" fix is to move this quota out of the listen queue and into some
I've had the usual reaction to the conspicuous consumption of the
current Netscape behavior, but I've also noticed that having the screen
fill in by several different images, rather than doing all of one first, is
pretty nice.
This makes me think that the web's use of tcp needs to have an
old-time "session" layer above it, for multiple data streams. Nothing as
heavy weight as the OSI stuff, of course, but a basic way of segmenting the
data stream. (It would help FTP, too, since it would eliminate the mess of
running FTP through firewalls.) Ah well, fantasizes modifications to the
infrastructure is always fun.
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09656;
21 Jul 96 15:48 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa10806; 21 Jul 96 15:48 EDT
Received: from ietf.org by ietf.org id aa14882; 21 Jul 96 15:48 EDT
Received: from core.atmnet.net by ietf.org id aa14835; 21 Jul 96 15:45 EDT
Received: from jfbb.atmnet.net (jfbb.atmnet.net [207.67.252.138]) by core.atmnet.net (8.7.5/8.6.9) with SMTP id MAA00628; Sun, 21 Jul 1996 12:45:00 -0700 (PDT)
Received: by jfbb.atmnet.net with Microsoft Mail
id <01BB7702.9810D320 at jfbb.atmnet.net>; Sun, 21 Jul 1996 12:46:10 -0700
Message-ID: <01BB7702.9810D320 at jfbb.atmnet.net>
Sender:ietf-request at ietf.org
From: Jim Browning <jfbb at atmnet.net>
To: 'Michael Dillon' <michael at memra.com>
Cc: "ietf at ietf.org" <ietf at ietf.org>, "newdom at iiia.org" <newdom at iiia.org>
Subject: RE: IETF WG charter IS needed for NEWDOM
Date: Sun, 21 Jul 1996 12:46:09 -0700
Encoding: 45 TEXT
Source-Info: From (or Sender) name not authenticated.
>From: Michael Dillon[SMTP:michael at memra.com]
>Sent: Saturday, July 20, 1996 4:26 PM
>
>On Sat, 20 Jul 1996, Fred Baker wrote:
>
>> The Operations and Applications Area Directors have put specific
questions
>> to the working group that need to be addressed in the charter and in the
>> outcome documentation.
>
>I don't recall seeing these but, as you point out, the discussion has
>taken a number of different tacks and I may have missed it.
Fred is referring to Scott Bradner's comments that he (please correct me if
my memory is wrong) would consider supporting a newdom WG if the charter
was drafted so that it included an analysis of the pros and cons of
additional TLDs, as opposed to assuming that they were appropriate. Taking
such an objective perspective would do nothing but improve our end product,
as it would point out areas of concern to be addressed.
We will get nowhere until we agree to a charter and milestones *anyway*, so
why not address IESG's concerns so that we can obtain an IETF charter?
Doing so will add (1) credibility with the IETF community which will
ultimately need to demonstrate consensus support of an RFC, (2) add
visibility for those who might be interested but not know about the newdom
list, and (3) provide some degree of protection form the legal liability we
may otherwise face. Not to mention the fact that we will obtain valuable
input from some very competent people.
Everyone should think long and hard about #3 before deciding we are
unwilling to take the (modest) additional steps necessary to obtain a WG
charter.
Let's focus on the charter and milestones until they are agreed to, and
move on with finding a solution. Given that there are already I-Ds being
reviewed, we have a solid basis for moving quickly.
Let's get on with it. We need a WG chair, a WG editor, a Charter, and some
milestones. Taking a look at what other WGs have done
<http://www.ietf.org/html.charters/wg-dir.html> will give everyone a good
idea of what's involved...
--
Jim Browning
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09916;
21 Jul 96 16:52 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa11456; 21 Jul 96 16:52 EDT
Received: from ietf.org by ietf.org id aa15754; 21 Jul 96 16:52 EDT
Received: from pinky.junction.net by ietf.org id aa15682; 21 Jul 96 16:48 EDT
Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id MAA22862; Sun, 21 Jul 1996 12:59:48 -0700
Received: from localhost (michael at localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id NAA15729; Sun, 21 Jul 1996 13:44:25 -0700
Date: Sun, 21 Jul 1996 13:44:24 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Michael Dillon <michael at memra.com>
To: "newdom at iiia.org" <newdom at iiia.org>
cc: "ietf at ietf.org" <ietf at ietf.org>
Subject: RE: IETF WG charter IS needed for NEWDOM
In-Reply-To: <01BB7702.9810D320 at jfbb.atmnet.net>
Message-ID: <Pine.BSI.3.93.960721133556.26371s-100000 at sidhe.memra.com>
Organization: Memra Software Inc. - Internet consulting
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sun, 21 Jul 1996, Jim Browning wrote:
> Fred is referring to Scott Bradner's comments that he (please correct me if
> my memory is wrong) would consider supporting a newdom WG if the charter
> was drafted so that it included an analysis of the pros and cons of
> additional TLDs, as opposed to assuming that they were appropriate. Taking
> such an objective perspective would do nothing but improve our end product,
> as it would point out areas of concern to be addressed.
Well a lot of that has already been adressed on NEWDOM so I have no
problem with including a pro/con analysis in the charter. In fact, I've
been thinking that it would be good to start reviewing a lot of the
material that has been posted in the past, but perhaps saying it in a less
verbose fashion. :-)
> We will get nowhere until we agree to a charter and milestones *anyway*, so
> why not address IESG's concerns so that we can obtain an IETF charter?
As long as we do the charter writing in open on the list, I have no
problem with that. Mostly what disturbed me about this iNIC charter was
that it seemed to be one or two people heading off into left field without
much discussion on the list.
> Let's get on with it. We need a WG chair,
I believe Bill Manning has been offered and accepted that position. Bill,
maybe you could clarify?
> a WG editor,
Well Jim, would you do this?
> a Charter,
We have a recent outline posted to NEWDOM and I believe three comments on
it so far. Let's work on the charter in a separate thread.
> and some
> milestones.
I'm going to post to NEWDOM in a spearate thread with the milestones from
Postel's last draft revision as a starting point.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael at memra.com
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10015;
21 Jul 96 17:05 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa11602; 21 Jul 96 17:05 EDT
Received: from ietf.org by ietf.org id aa15959; 21 Jul 96 17:05 EDT
Received: from pinky.junction.net by ietf.org id aa15912; 21 Jul 96 17:03 EDT
Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id NAA23040; Sun, 21 Jul 1996 13:14:49 -0700
Received: from localhost (michael at localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id NAA15840; Sun, 21 Jul 1996 13:59:27 -0700
Date: Sun, 21 Jul 1996 13:59:25 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Michael Dillon <michael at memra.com>
To: "newdom at iiia.org" <newdom at iiia.org>
cc: "ietf at ietf.org" <ietf at ietf.org>
Subject: NEWDOM WG charter to address need for new iTLD's
In-Reply-To: <01BB7702.9810D320 at jfbb.atmnet.net>
Message-ID: <Pine.BSI.3.93.960721135249.26371v-100000 at sidhe.memra.com>
Organization: Memra Software Inc. - Internet consulting
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sun, 21 Jul 1996, Jim Browning wrote:
> Fred is referring to Scott Bradner's comments that he (please correct me if
> my memory is wrong) would consider supporting a newdom WG if the charter
> was drafted so that it included an analysis of the pros and cons of
> additional TLDs, as opposed to assuming that they were appropriate.
I am going to assume that the following words of Scott Bradner are the key
ones then:
> I have severe reservations myself (as I have posted from time to time).
> I would much rather a working group that has as part of its charter to
> figure out if new TLDs gain more than they lose.
> If the charter included the investigation of the advantages and
> disadvantages of new TLDs than, whatever the outcome (as long as it was
> openly reached and represented consensus of the working group) I could
> support it. But that is not what I'm seeing here.
I don't see anything fundamentally wrong with this suggestion from Scott
and I think it is certainly worthwhile to review a lot of the pro/con
discussions that happened on the list in the past. In fact, it would be
worthwhile to include a pro/con summary within the RFC because after we
have a year of experience with new iTLD's under our belt we should review
that in light of the list of pros and cons to see if we came up with the
best solution.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael at memra.com
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10106;
21 Jul 96 17:30 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa11832; 21 Jul 96 17:30 EDT
Received: from ietf.org by ietf.org id aa16245; 21 Jul 96 17:29 EDT
Received: from core.atmnet.net by ietf.org id aa16190; 21 Jul 96 17:28 EDT
Received: from jfbb.atmnet.net (jfbb.atmnet.net [207.67.252.138]) by core.atmnet.net (8.7.5/8.6.9) with SMTP id OAA01270; Sun, 21 Jul 1996 14:27:30 -0700 (PDT)
Received: by jfbb.atmnet.net with Microsoft Mail
id <01BB7710.F79156E0 at jfbb.atmnet.net>; Sun, 21 Jul 1996 14:29:03 -0700
Message-ID: <01BB7710.F79156E0 at jfbb.atmnet.net>
Sender:ietf-request at ietf.org
From: Jim Browning <jfbb at atmnet.net>
To: 'Michael Dillon' <michael at memra.com>
Cc: "ietf at ietf.org" <ietf at ietf.org>, "newdom at iiia.org" <newdom at iiia.org>
Subject: RE: IETF WG charter IS needed for NEWDOM
Date: Sun, 21 Jul 1996 14:29:02 -0700
Encoding: 31 TEXT
Source-Info: From (or Sender) name not authenticated.
>From: Michael Dillon[SMTP:michael at memra.com]
>Sent: Sunday, July 21, 1996 6:44 AM
>
>> Let's get on with it. We need a WG chair,
>
>I believe Bill Manning has been offered and accepted that position. Bill,
>maybe you could clarify?
And use your experience and expertise to help keep us on track towards our
objectives (like achieving an acceptable Charter)? Are you in agreement
that this is the proper approach?
>> a WG editor,
>
>Well Jim, would you do this?
I would say "I'm too busy", but that would be a cop out, as we all are. I
have one valid reservation in that I am traveling a whole lot right now,
some of it to far off places where my connectivity is severely restricted.
There are periods where I am for all intents and purposes "off-line" for a
few days, and unable to timely process all the traffic. If I am to be the
keeper of the documents, there may be processing delays. I would see the
role as incorporating comments to the documents, ensuring that Bill (as WG
chair) agrees that the changes reflect the groups consensus, and then
distributing the new versions to the list. If people will accept my
limitations and my definition of the role, then I will (in a "put up or
shut up" mode), do my best.
--
Jim Browning <jfbb at atmnet.net>
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11042;
21 Jul 96 21:19 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa14053; 21 Jul 96 21:19 EDT
Received: from ietf.org by ietf.org id aa19287; 21 Jul 96 21:19 EDT
Received: from smtp2.interramp.com by ietf.org id aa19170; 21 Jul 96 21:10 EDT
Received: from ir001264 by smtp2.interramp.com (8.6.12/SMI-4.1.3-PSI-irsmtp)
id VAA19438; Sun, 21 Jul 1996 21:10:25 -0400
Message-Id: <199607220110.VAA19438 at smtp2.interramp.com>
Comments: Authenticated sender is <ir001264 at pop3.interramp.com>
Sender:ietf-request at ietf.org
From: Marty Modell <ir001264 at interramp.com>
To: Jim Browning <jfbb at atmnet.net>, "ietf at ietf.org" <ietf at ietf.org>,
"newdom at iiia.org" <newdom at iiia.org>
Date: Sun, 21 Jul 1996 21:10:22 +0000
Subject: RE: IETF WG charter IS needed for NEWDOM
Priority: normal
X-mailer: Pegasus Mail for Win32 (v2.42)
Source-Info: From (or Sender) name not authenticated.
> Let's focus on the charter and milestones until they are agreed to, and
> move on with finding a solution. Given that there are already I-Ds being
> reviewed, we have a solid basis for moving quickly.
>
> Let's get on with it. We need a WG chair, a WG editor, a Charter, and some
> milestones. Taking a look at what other WGs have done
> <http://www.ietf.org/html.charters/wg-dir.html> will give everyone a good
> idea of what's involved...
If you need volunteers I would be willing. I am not sure what I can
contribute but the spirit is willing.
--
Marty Modell e-mail: ir001264 at interramp.com
author of
A Professional's Guide to Systems Analysis
Second Edition - McGraw Hill - 1996
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06435;
22 Jul 96 4:13 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa03376; 22 Jul 96 4:13 EDT
Received: from ietf.org by ietf.org id aa01112; 22 Jul 96 4:13 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa01037; 22 Jul 96 4:09 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06397;
22 Jul 96 4:09 EDT
Received: from KOOBERA.MATH.UIC.EDU by CNRI.Reston.VA.US id aa03320;
22 Jul 96 4:09 EDT
Received: (qmail-queue invoked by uid 666); 22 Jul 1996 08:13:39 -0000
Date: 22 Jul 1996 08:13:39 -0000
Message-ID: <19960722081339.26324.qmail at koobera.math.uic.edu>
Sender:ietf-request at ietf.org
From: "D. J. Bernstein" <djb at koobera.math.uic.edu>
To: ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms
Source-Info: From (or Sender) name not authenticated.
> This sounds like the httpd hack I did a while back that rejects concurrent
> connections from the same host, thus defeating Netscape's odd habit of opening
> lots of simultaneous HTTP connections to the same place at the same time "to
> get better service."
Your hack ends up (1) increasing the per-user load on your host, (2)
increasing the per-user load on the network, and (3) annoying the users.
What exactly was the benefit supposed to be?
If you're worried about the problem of your machine running out of
memory at peak moments, attack that problem directly. Figure out how
many concurrent HTTP servers you can handle at once. Don't run more than
that. If another request comes in when you're at the limit, delay your
response until a slot frees up. Don't throw away connections; that would
waste valuable packets.
If you're worried about the ``fairness'' of first-in-first-out service
when the same user can be first four times in a row, look at it from the
point of view of the users. If you cycle among ten users for 30 seconds,
_all_ of the users will have to wait 30 seconds. If you instead handle
the first user first, the second user second, and so on, the average
latency will drop below 17 seconds. (The difference is even more
pronounced over links that are limited by RTTs rather than bandwidth.)
Finally, if you're trying to optimize TCP's retransmit strategy across a
bunch of connections rather than a single connection at once, go ahead
and write some software. Multiple connections could in principle be
treated as a single connection with a very large window. Yes, this will
take work; did you really expect that a quick hack would solve anything?
---Dan
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06587;
22 Jul 96 4:50 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa03709; 22 Jul 96 4:50 EDT
Received: from ietf.org by ietf.org id aa01821; 22 Jul 96 4:50 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa01774; 22 Jul 96 4:48 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06575;
22 Jul 96 4:48 EDT
Received: from bells.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa03689;
22 Jul 96 4:48 EDT
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.06006-0 at bells.cs.ucl.ac.uk>; Mon, 22 Jul 1996 09:48:12 +0100
To: "D. J. Bernstein" <djb at koobera.math.uic.edu>
cc: ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: TCP Slow Start, Congestion Avoidance, Fast Retransmit,
and Fast Recovery Algorithms
In-reply-to: Your message of "22 Jul 1996 08:13:39 -0000." <19960722081339.26324.qmail at koobera.math.uic.edu>
Date: Mon, 22 Jul 1996 09:48:09 +0100
Message-ID: <903.838025289 at cs.ucl.ac.uk>
Sender:ietf-request at ietf.org
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Source-Info: From (or Sender) name not authenticated.
>If you're worried about the ``fairness'' of first-in-first-out service
yes...
If you want fairness o nthe net, you need admission contr0ol (or a
fair discard scheme such as RED)
A scheme such as this might enforce fairness in use of web server
resources (i.e. HTTP GET per Sec per Source), but might do horrible
things to the net...
jon
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09338;
22 Jul 96 10:05 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa07253; 22 Jul 96 10:05 EDT
Received: from ietf.org by ietf.org id aa06950; 22 Jul 96 10:05 EDT
Received: from localhost by ietf.org id aa06453; 22 Jul 96 9:57 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: srv-location at tgv.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-svrloc-IPv6-00.txt
Date: Mon, 22 Jul 1996 09:57:41 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607220957.aa06453 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Service Location Protocol
Working Group of the IETF.
Title : Service Location Modifications for IPv6
Author(s) : J. Veizades, E. Guttman
Filename : draft-ietf-svrloc-IPv6-00.txt
Pages : 5
Date : 07/16/1996
The Service Location Protocol provides a scalable framework for the
discovery and selection of network services. Using this protocol,
computers using the Internet no longer need so much static configuration of
network services for network based applications. This is especially
important as computers become more portable, and users less tolerant or
able to fulfill the demands of network administration.
The Service Location Protocol is well defined for use over IPv4 networks
[SLP]: This document defines its use over IPv6 networks. Since this
protocol relies on UDP and TCP, the changes to support its use over IPv6
are minor.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-svrloc-IPv6-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-IPv6-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-svrloc-IPv6-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960717093020.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-svrloc-IPv6-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-svrloc-IPv6-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960717093020.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09378;
22 Jul 96 10:05 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa07266; 22 Jul 96 10:05 EDT
Received: from ietf.org by ietf.org id aa06939; 22 Jul 96 10:05 EDT
Received: from localhost by ietf.org id aa06377; 22 Jul 96 9:56 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-pppext-bacp-04.txt
Date: Mon, 22 Jul 1996 09:56:34 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607220956.aa06377 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : The PPP Bandwidth Allocation Protocol (BAP)
The PPP Bandwidth Allocation Control Protocol (BACP)
Author(s) : C. Richards, K. Smith
Filename : draft-ietf-pppext-bacp-04.txt
Pages : 22
Date : 07/17/1996
This document proposes a method to manage the dynamic bandwidth allocation
of implementations supporting the PPP multilink protocol [2]. This is done
by defining the Bandwidth Allocation Protocol (BAP), as well as its
associated control protocol, the Bandwidth Allocation Control Protocol
(BACP). BAP can be used to manage the number of links in a multilink
bundle. BAP defines datagrams to co-ordinate adding and removing
individual links in a multilink bundle, as well as specifying which peer is
responsible for which decisions regarding managing bandwidth during a
multilink connection.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pppext-bacp-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-bacp-04.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-bacp-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960717164147.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-bacp-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-bacp-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960717164147.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09398;
22 Jul 96 10:05 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa07265; 22 Jul 96 10:05 EDT
Received: from ietf.org by ietf.org id aa06948; 22 Jul 96 10:05 EDT
Received: from localhost by ietf.org id aa06704; 22 Jul 96 9:59 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at list.cren.net
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mailext-new-fields-05.txt
Date: Mon, 22 Jul 1996 09:59:38 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607220959.aa06704 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working
Group of the IETF.
Title : The Supersedes and Expires e-mail headers
Author(s) : J. Palme
Filename : draft-ietf-mailext-new-fields-05.txt
Pages : 5
Date : 07/17/1996
This memo introduces two new e-mail (RFC 822) headers, Supersedes, and
Expires. The postscript version of this IETF draft shows the differences
from its previous version.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mailext-new-fields-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mailext-new-fields-05.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mailext-new-fields-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960717102310.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-new-fields-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-new-fields-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960717102310.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09459;
22 Jul 96 10:05 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa07298; 22 Jul 96 10:05 EDT
Received: from ietf.org by ietf.org id aa07083; 22 Jul 96 10:05 EDT
Received: from localhost by ietf.org id aa06871; 22 Jul 96 10:02 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mhtml at segate.sunet.se
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mhtml-info-01.txt, .ps
Date: Mon, 22 Jul 1996 10:02:12 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607221002.aa06871 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MIME Encapsulation of
Aggregate HTML Documents Working Group of the IETF.
Title : Sending HTML in E-mail, an informational supplement to
RFC ???: MIME E-mail Encapsulation of Aggregate HTML
Documents (MHTML)
Author(s) : J. Palme
Filename : draft-ietf-mhtml-info-01.txt, .ps
Pages : 9
Date : 07/17/1996
The memo "MIME E-mail Encapsulation of Aggregate HTML Documents (MHTML)"
(draft-ietf-mhtml-spec-00.txt) specifies how to send packaged aggregate
HTML objects in MIME e-mail. This memo is an accompanying informational
document, intended to be an aid to developers. This document is not an
Internet standard.
Issues discussed are implementation methods, caching strategies, making
messages suitable both for mailers which can and which cannot handle
Multipart/related and handling recipients which do not have full Internet
connectivity.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mhtml-info-01.txt".
Or
"get draft-ietf-mhtml-info-01.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mhtml-info-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mhtml-info-01.txt".
Or
"FILE /internet-drafts/draft-ietf-mhtml-info-01.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960717103557.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mhtml-info-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mhtml-info-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960717103557.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09476;
22 Jul 96 10:05 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa07279; 22 Jul 96 10:05 EDT
Received: from ietf.org by ietf.org id aa07029; 22 Jul 96 10:05 EDT
Received: from localhost by ietf.org id aa06818; 22 Jul 96 10:01 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mhtml at segate.sunet.se
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mhtml-spec-01.txt, .ps
Date: Mon, 22 Jul 1996 10:01:08 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607221001.aa06818 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MIME Encapsulation of
Aggregate HTML Documents Working Group of the IETF.
Title : MIME E-mail Encapsulation of Aggregate HTML Documents
(MHTML)
Author(s) : J. Palme, A. Hopman
Filename : draft-ietf-mhtml-spec-01.txt, .ps
Pages : 17
Date : 07/17/1996
Although HTML [RFC 1866] was designed within the context of MIME, more than
the specification of HTML as defined in RFC 1866 is needed for two
electronic mail user agents to be able to interoperate using HTML as a
document format. These issues include the naming of objects that are
normally referred to by URIs, and the means of aggregating objects that go
together. This document describes a set of guidelines that will allow
conforming mail user agents to be able to send, deliver and display these
HTML objects. In addition it is hoped that these techniques will also apply
to the wider category of URI-enabled objects. In order to do this, the
document specifies the MIME content-headers "Content-Location" and
Content-Base".
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mhtml-spec-01.txt".
Or
"get draft-ietf-mhtml-spec-01.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mhtml-spec-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mhtml-spec-01.txt".
Or
"FILE /internet-drafts/draft-ietf-mhtml-spec-01.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960717103116.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mhtml-spec-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mhtml-spec-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960717103116.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09481;
22 Jul 96 10:06 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa07277; 22 Jul 96 10:05 EDT
Received: from ietf.org by ietf.org id aa06938; 22 Jul 96 10:05 EDT
Received: from localhost by ietf.org id aa06597; 22 Jul 96 9:58 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-palme-int-print-00.txt
Date: Mon, 22 Jul 1996 09:58:41 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607220958.aa06597 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Making Postscript and Acrobat Files International
Author(s) : J. Palme
Filename : draft-palme-int-print-00.txt
Pages : 3
Date : 07/17/1996
Certain text formats, for example Postscript (extension .ps) and Adobe
Acrobat (extension .pdf) specify exactly the page layout of the printed
document. The commonly used paper format is different in America and the
rest of the world. America uses the "Letter" format, while the rest of the
world uses the "A4" format This means that documents formatted on one
continent may not be printable on another continent. This memo gives advice
on how to produce documents which are equally well printable with the
Letter and the A4 formats. By using the advice in this document, you can
put up a document on the Internet, which recipients can print without
problem both in and outside America.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-palme-int-print-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-palme-int-print-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-palme-int-print-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960717102015.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-palme-int-print-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-palme-int-print-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960717102015.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09468;
22 Jul 96 10:05 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa07267; 22 Jul 96 10:05 EDT
Received: from ietf.org by ietf.org id aa06941; 22 Jul 96 10:05 EDT
Received: from localhost by ietf.org id aa06259; 22 Jul 96 9:54 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ion at nexen.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rolc-nhrp-09.txt
Date: Mon, 22 Jul 1996 09:54:33 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607220954.aa06259 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internetworking Over NBMA
Working Group of the IETF.
Title : NBMA Next Hop Resolution Protocol (NHRP)
Author(s) : J. Luciani, D. Katz, D. Piscitello, B. Cole
Filename : draft-ietf-rolc-nhrp-09.txt
Pages : 46
Date : 07/18/1996
This document describes the NBMA Next Hop Resolution Protocol (NHRP). NHRP
can be used by a source station (host or router) connected to a
Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the
internetworking layer address and NBMA subnetwork addresses of the "NBMA
next hop" towards a destination station. If the destination is connected
to the NBMA subnetwork, then the NBMA next hop is the destination station
itself. Otherwise, the NBMA next hop is the egress router from the NBMA
subnetwork that is "nearest" to the destination station. NHRP is intended
for use in a multiprotocol internetworking layer environment over NBMA
subnetworks.
This document is intended to be a functional superset of the NBMA
Address Resolution Protocol (NARP) documented in [1].
Operation of NHRP as a means of establishing a transit path across
an NBMA subnetwork between two routers will be addressed
in a separate document.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rolc-nhrp-09.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rolc-nhrp-09.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rolc-nhrp-09.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960719141849.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rolc-nhrp-09.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rolc-nhrp-09.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960719141849.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09550;
22 Jul 96 10:06 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09470;
22 Jul 96 10:05 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa07268; 22 Jul 96 10:05 EDT
Received: from ietf.org by ietf.org id aa06951; 22 Jul 96 10:05 EDT
Received: from localhost by ietf.org id aa05976; 22 Jul 96 9:48 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dhcp-v4 at bucknell.edu
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dhc-dhcp-dns-01.txt
Date: Mon, 22 Jul 1996 09:48:11 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607220948.aa05976 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Dynamic Host Configuration
Working Group of the IETF.
Title : Interaction between DHCP and DNS
Author(s) : Y. Rekhter
Filename : draft-ietf-dhc-dhcp-dns-01.txt
Pages : 6
Date : 07/19/1996
DHCP provides a powerful mechanism for IP host autoconfiguration. However,
the autoconfiguration provided by DHCP does not include updating DNS, and
specifically updating the name to address and address to name mappings
maintained by DNS.
This document specifies how DHCP clients and servers should use the Dynamic
DNS Updates mechanism to update the DNS name to address and address to name
mapping, so that the mappings for DHCP clients would be consistent with the
IP addresses that the clients acquire via DHCP.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-dhcp-dns-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-dhcp-dns-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dhc-dhcp-dns-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960719171820.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-dhcp-dns-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-dhcp-dns-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960719171820.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09561;
22 Jul 96 10:06 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09480;
22 Jul 96 10:06 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa07278; 22 Jul 96 10:05 EDT
Received: from ietf.org by ietf.org id aa06947; 22 Jul 96 10:05 EDT
Received: from localhost by ietf.org id aa06135; 22 Jul 96 9:52 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: http-wg at cuckoo.hpl.hp.com
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-http-state-mgmt-03.txt, .ps
Date: Mon, 22 Jul 1996 09:52:40 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607220952.aa06135 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Transfer Protocol
Working Group of the IETF.
Title : Proposed HTTP State Management Mechanism
Author(s) : D. Kristol, L. Montulli
Filename : draft-ietf-http-state-mgmt-03.txt, .ps
Pages : 19
Date : 07/19/1996
This document specifies a way to create a stateful session with HTTP
requests and responses. It describes two new headers, Cookie and requests
and responses. It describes two new headers, Cookie and Set-Cookie, which
carry state information between participating origin servers and user
agents. The method described here differs from Netscape's Cookie proposal,
but it can interoperate with HTTP/1.0 user agents that use Netscape's
method. (See the HISTORICAL section.)
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-http-state-mgmt-03.txt".
Or
"get draft-ietf-http-state-mgmt-03.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-state-mgmt-03.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-http-state-mgmt-03.txt".
Or
"FILE /internet-drafts/draft-ietf-http-state-mgmt-03.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960719170321.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-state-mgmt-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-state-mgmt-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960719170321.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09562;
22 Jul 96 10:06 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09483;
22 Jul 96 10:06 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa07280; 22 Jul 96 10:05 EDT
Received: from ietf.org by ietf.org id aa06946; 22 Jul 96 10:05 EDT
Received: from localhost by ietf.org id aa06048; 22 Jul 96 9:50 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-oleary-icap-00.txt
Date: Mon, 22 Jul 1996 09:50:14 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607220950.aa06048 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Internet Calendar Access Protocol (ICAP)
Author(s) : P. O'Leary
Filename : draft-oleary-icap-00.txt
Pages : 17
Date : 07/19/1996
This Internet Calendar Access Protocol (ICAP) allows a client to access,
manipulate and store Calendar information on a server. ICAP can be used
either as a set of capability extensions to IMAP4 [1] to create a server
which supports both messaging and calendaring functions, or as a standalone
protocol for a server dedicated to calendaring only. ICAP employs the
vCalendar format [2] for interchange of calendaring information.
ICAP includes operations for creating Calendar stores on a server, opening
them and retrieving information about them. When a Calendar store has been
opened, it can be bounded by start and end times so that the client can act
on a smaller subset of Calendar information for more efficient operation.
ICAP allows users to store new Calendar entries into their own Calendar
store and Calendar stores owned by other users with a single operation.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-oleary-icap-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-oleary-icap-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-oleary-icap-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960719171220.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-oleary-icap-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-oleary-icap-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960719171220.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09851;
22 Jul 96 10:08 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa07356; 22 Jul 96 10:08 EDT
Received: from ietf.org by ietf.org id aa07393; 22 Jul 96 10:08 EDT
Received: from localhost by ietf.org id aa07037; 22 Jul 96 10:04 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-thayer-seccomp-00.txt
Date: Mon, 22 Jul 1996 10:04:32 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607221004.aa07037 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Compression Payload for Use with IP Security
Author(s) : R. Thayer
Filename : draft-thayer-seccomp-00.txt
Pages : 4
Date : 07/17/1996
This document describes a payload format to be used to store compressed
protocol messages within an IP packet which is using security features as
defined in [RFC-1825].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-thayer-seccomp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-thayer-seccomp-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-thayer-seccomp-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960717141737.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-thayer-seccomp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-thayer-seccomp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960717141737.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09944;
22 Jul 96 10:10 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa07383; 22 Jul 96 10:10 EDT
Received: from ietf.org by ietf.org id aa07474; 22 Jul 96 10:10 EDT
Received: from localhost by ietf.org id aa07360; 22 Jul 96 10:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-andrews-dns-more-02.txt
Date: Mon, 22 Jul 1996 10:07:05 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607221007.aa07360 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Large Responses to DNS Queries (DNS MORE)
Author(s) : M. Andrews, P. Vixie
Filename : draft-andrews-dns-more-02.txt
Pages : 5
Date : 07/17/1996
DNS messages are limited to 64 kilobytes in size. At times it is necessary
to send a message that is greater that 64 kilobytes. This is currently not
possible. AXFR is the one exception. This document describes how to send a
sequence of messages, the total length which may be greater than 64
kilobytes, by extending the protocol.
In addition average message sizes are increasing and the 512 byte payload
limit for UDP is now too small. This document describes how servers can
identify when they can send bigger messages without necessarily resorting
to TCP.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-andrews-dns-more-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-andrews-dns-more-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-andrews-dns-more-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960722100534.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-andrews-dns-more-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-andrews-dns-more-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960722100534.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10102;
22 Jul 96 10:15 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa07469; 22 Jul 96 10:15 EDT
Received: from ietf.org by ietf.org id aa07676; 22 Jul 96 10:15 EDT
Received: from localhost by ietf.org id aa07585; 22 Jul 96 10:12 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at list.cren.net
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mailext-mail-attributes-05.txt
Date: Mon, 22 Jul 1996 10:12:24 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607221012.aa07585 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working
Group of the IETF.
Title : Common Internet Message Headers
Author(s) : J. Palme
Filename : draft-ietf-mailext-mail-attributes-05.txt
Pages : 24
Date : 07/17/1996
This memo contains a table of commonly occurring headers in headings of
e-mail messages. The document compiles information from other RFCs such as
RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766, RFC
1806, RFC 1864 and RFC 1911. A few commonly occurring headers which are not
defined in RFCs are also included. For each header, the memo gives a short
description and a reference to the RFC in which the header is defined.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mailext-mail-attributes-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mailext-mail-attributes-05.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mailext-mail-attributes-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960717104050.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-mail-attributes-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-mail-attributes-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960717104050.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10681;
22 Jul 96 10:56 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa08052; 22 Jul 96 10:56 EDT
Received: from ietf.org by ietf.org id aa08851; 22 Jul 96 10:56 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa08770;
22 Jul 96 10:52 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10564;
22 Jul 96 10:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07995;
22 Jul 96 10:52 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10557;
22 Jul 96 10:52 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: "Data: URL scheme" to Proposed Standard
Reply-to: iesg at ietf.org
Date: Mon, 22 Jul 96 10:52:20 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9607221052.aa10557 at IETF.CNRI.Reston.VA.US>
The IESG has received a request to consider "Data: URL scheme"
<draft-masinter-url-data-01.txt> as a Proposed Standard. This has
been reviewed in the IETF but is not the product of an IETF Working
Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by August 22, 1996.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12746;
22 Jul 96 13:21 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa10322; 22 Jul 96 13:21 EDT
Received: from ietf.org by ietf.org id aa14713; 22 Jul 96 13:21 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa14430;
22 Jul 96 13:19 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12679;
22 Jul 96 13:19 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10266;
22 Jul 96 13:19 EDT
Received: from mail-d.bcc.ac.uk by venera.isi.edu (5.65c/5.61+local-25)
id <AA29433>; Mon, 22 Jul 1996 10:18:54 -0700
Received: from busby (actually busby.ee.ucl.ac.uk) by mail-d.bcc.ac.uk
with SMTP (PP); Mon, 22 Jul 1996 18:13:46 +0100
Sender:ietf-request at ietf.org
From: a.galis at eleceng.ucl.ac.uk
Received: from [128.40.40.86] (ee-at8th-mac86) by busby;
Mon, 22 Jul 96 18:13:23 BST
X-Sender: agalis at busby
Message-Id: <v02130506ae1972f9921d at [128.40.40.86]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 22 Jul 1996 18:15:00 +0000
To: ss96 at greco.dit.upm.es, SS96 Distribution List <ss96 at sanson.dit.upm.es>,
cnom at maestro.bellcore.com, tccc at cs.umass.edu, osimcast at bbn.com,
sc6wg4 at ntd.comsat.com, hipparch at sophia.inria.fr, reres at laas.fr,
prs at masi.ibp.fr, ieeetcpc at ccvm.sunysb.edu, comswtc at gmu.edu,
multicomm at cc.bellcore.com, giga at tele.pitt.edu, isadsoc at fokus.gmd.de,
ctc-members at redbank.tinac.com, ieee_rtc_list at cs.tamu.edu,
enternet at bbn.com, cnom at maestro.bellcore.com,
gcomlist1 at manjaro.ece.iit.edu, comsoc.bog at tab.ieee.org,
sigmedia at bellcore.com, comsoc.tac at tab.ieee.org, comsoc-gicb at ieee.org,
commsoft at cc.bellcore.com, BM-Mist1 at cs.ucdavis.edu,
modern-heuristics at uk.ac.mailbase.ucdavis.edu, alg at comm.toronto.edu,
cellular at dfv.rwth-aachen.edu, cost237-transport at comp.lancs.ac.uk,
testnet at canarie.ca, igawdan at bnr.ca, end2end-interest at isi.edu,
f-troup at aurora.cis.upenn.edu, g-troup at dworkin.wustl.edu, ietf at isi.edu,
rem-conf-request at es.net, Med Inf List <ag-exp-l at ndsuvm1.bitnet>,
agosta at sumex-aim.stanford.edu, ai-ed at sun.com,
ai-medicine at croquet.stanford.edu, ai-nat at adfa.oz.au,
ai-stats at watstat.uwaterloo.ca, aisb at cogs.sussex.ac.uk,
announcements.chi at xerox.com, arl at arl.wustl.edu,
arpanet-bboard at mc.lcs.mit.edu, atm at bbn.com, ccrc at dworkin.wustl.edu,
cellular at dfv.rwth-aachen.de, cip at bbn.com, cnom at maestro.bellcore.com,
cogsci at cogsci.ed.ac.uk, cybsys-l at bingvmb.cc.binghamton.edu,
diagrams at cs.swarthmore.edu, elsnet-list at cogsci.edinburgh.ac.uk,
end2end-interest at isi.edu, enternet-ec at bbn.com, enternet at bbn.com,
f-troup at aurora.cis.upenn.edu, fj-ai at etl.go.jp, g-troup at dworkin.wustl.edu,
globecom at signet.com.sg, hipparch at sophia.inria.fr,
icad-request at santafe.edu, IE-list at cs.ucl.ac.uk, ietf at isi.edu,
ikbsbb at inf.rl.ac.uk, iplpdn at CNRI.Reston.VA.US, ircpeople at cogsci.ed.ac.uk,
John Lee <john at caad.ed.ac.uk>, kdd at gte.com, met-ai at comp.vuw.ac.nz,
mmws at caad.ed.ac.uk, perform at tay1.dec.com, rem-conf at es.net,
schulzrinne at fokus.gmd.de, sig11 at roses.stanford.edu, sigmedia at bellcore.com,
smds at CNRI.Reston.VA.US, sound at acm.org, tccc at cs.umass.edu, tcplw at cray.com,
tf-mm at i4serv.informatik.rwth-aachen.de, uist.chi at xerox.com,
xtp-relay at cs.concordia.ca, Med Inf List <ag-exp-l at ndsuvm1.bitnet>,
agosta at sumex-aim.stanford.edu, ai-ed at sun.com,
ai-medicine at croquet.stanford.edu, ai-nat at adfa.oz.au,
ai-stats at watstat.uwaterloo.ca, aisb at cogs.sussex.ac.uk,
announcements.chi at xerox.com, arl at arl.wustl.edu,
arpanet-bboard at mc.lcs.mit.edu, atm at bbn.com, ccrc at dworkin.wustl.edu,
cellular at dfv.rwth-aachen.de, cip at bbn.com
Source-Info: From (or Sender) name not authenticated.
cnom at maestro.bellcore.com,
cogsci at cogsci.ed.ac.uk, cybsys-l at bingvmb.cc.binghamton.edu,
diagrams at cs.swarthmore.edu, elsnet-list at cogsci.edinburgh.ac.uk,
end2end-interest at isi.edu, enternet-ec at bbn.com, enternet at bbn.com,
f-troup at aurora.cis.upenn.edu, fj-ai at etl.go.jp, g-troup at dworkin.wustl.edu,
globecom at signet.com.sg, hipparch at sophia.inria.fr, icad-request at santafe.edu,
IE-list at cs.ucl.ac.uk, ietf at isi.edu, ikbsbb at inf.rl.ac.uk,
iplpdn at cnri.reston.va.us, ircpeople at cogsci.ed.ac.uk,
John Lee <john at caad.ed.ac.uk>, kdd at gte.com, met-ai at comp.vuw.ac.nz,
mmws at caad.ed.ac.uk, perform at tay1.dec.com, rem-conf at es.net,
schulzrinne at fokus.gmd.de, sig11 at roses.stanford.edu, sigmedia at bellcore.com,
smds at cnri.reston.va.us, sound at ACM.ORG, tccc at cs.umass.edu, tcplw at cray.com,
tf-mm at i4serv.informatik.rwth-aachen.de, uist.chi at xerox.com,
xtp-relay at cs.concordia.ca, ytw at hoserve.ho.att.com,
epmcc_distribution at comnets.rwth-aachen.de, COMSWTC at gmu.edu,
sigmedia at bellcore.com, jdc at mojave.ece.arizona.edu
From: a.galis (Alex Galis)
Subject: GLOBCOM'96 London U.K. / 18-22 November 1996
Cc: a.galis at busby, c.todd at busby
Dear All,
In the name of the Organising Committee I am pleased to invite you to
attend GLOBCOM'96 Telecommunications Conference organised by IEEE in London
( 18th - 22nd November 1996).
Yours sincerely
Alex Galis
University College London
............................................................................
...........................
1996 IEEE GLOBAL TELECOMMUNICATIONS CONFERENCE
18th - 22nd November 1996
Queen Elizabeth II Conference Centre, Westminster, London
"Communications: The Key to Global Prosperity"
This major international communications conference, held annually for some
25 years, is to be hosted in London for its first staging in Europe.
Sponsored by the IEEE Communications Society and in conjunction with the
IEE, Globecom 96 aims to attract 1000+ of the leading telecommunication
development engineers, academics, operators and manufacturers from all parts
of the world.
The Conference will consist of 50 Technical Sessions (in 9 parallel tracks),
6 Sessions of a Mini-Conference on Communications Theory, 4 Sessions of a
Mini-Conference called "IEEE Global Internet '96" and 4 Panel Session
discussions on key Business Topics over the 3 days (Tuesday 19th, Wednesday
20th and Thursday 21st November 1996). On Monday 18th and Friday 22nd
November there will be some 27 half-day equivalent sessions devoted to
Tutorials and Workshops on key Hot Topics. Throughout the week there will
be a 20 stand Exhibition of sponsoring companies, publishers and future
ComSoc Conferences. In addition there will be a separate Exhibition on
Internet and related telecomms topics.
Hot Topics
The Hot Topics below have been identified by the ComSoc Technical
Committees. These titles have been accepted by the Globecom '96 Technical
Programme Committee as forming a basis on which to assemble Technical
Session and Tutorials etc.
- Advances in PCS
- Wireless ATM
- Advanced switching architectures for broadband networks
- Network issues in wireless communications
- Distributed Software Challenges
- Software Support for Interactive MultiMedia Services and Applications
- Wireless Communication and ATM
- Towards ATM Switching Systems with Terabit/s Capacity
- Signal Processing for Multimedia Services
- Advanced VLSI Signal Processing in Communications
- Quality of service for advanced communication services (PCS, Multimedia,
Internet)
- Software engineering technologies and experience to Improve and sustain
network quality objectives
- Mobile Satellite Communications
- Satellite Communications for Broadband Networks
- Security and Privacy in the GII/NII
- Multicasting
- Multimedia over the Internet
- Interactive Video Applications and Supporting Technologies
- Optical Access Networks and New Services Development
- Very High-Speed ( OC-192) Optical Transmission
Panel Sessions
These will consist of short presentations followed by discussion, lead by a
group of the leading Global Players on the Topics of:-
1. Visions of the 21st Century
2. Wireless revolution towards global roaming
3. The Information highway - market and service provider perspectives
4. Service and quality: customer's perceptions
Tutorials and Workshops - mixture of full and half day Sessions
The titles and leaders are:
Monday tutorials and workshop
T01 Telecommunications Management Network:- Standards, Implementation and
Applications (Veli Sahin, NEC America Inc)
T02 Introduction to ATM (Khosrow Sohraby, IBM)
T03 GSM - Recent Advances and Future Developments (Paul Kakaes, Cosmos
Communications Consulting)
T04 Traffic Modelling and Management in Wireless Communications Systems
(am) (Sirin Tekinay, Bell Northern Research)
T05 Modelling and Transmission issues for VBR video over B-ISDN Networks
(am) (Dr Ghanbari, University of Essex)
T06 High Speed Wireless Data (Len Cimini, AT&T Bell Laboratories and Andrea
Goldsmith, California Institute of Technology)
T07 JAVA (Prof John N Daigle)
T08 The Intelligent Network and Mobile System Control (pm) (Prof Bijan
Jabbari, George Mason University)
T09 Iterative Turbo-Decoding (pm) (Joachim Hagenauer, TU Munich)
T10 Interactive Multimedia over the Internet (pm) (Mark Handley and Ian
Wakemen, UCL and Sussex University)
W01 Very-high-speed Digital Subscriber Lines (Prof John M Cioffi, Stanford
University)
Friday tutorials and workshop
T11 Mobile and Multimedia Satellite Systems (Dr K M S Murthy, VISTAR
Telecommunications)
T12 Spread Spectrum Systems for PCS (Elvino S Sousa, University of Toronto)
T13 Mobility Management in TCP/IP Networks (Dr Zygmunt Haas, Cornell
University)
T14 Operation and Management of Multi-Wavelength Optical Networks (am) (Dr
Mari Maeda, Bell Communications Research)
T15 Internet IP Security (am) ( Ran Atkinson, Internet Security)
T16 Adaptive Antennas for Wireless Systems (pm) (Jack Winters, AT&T Bell
Laboratories)
T17 IP and ATM - Enterprise Internetworking (pm) (David Ginsburg, CISCO
Corp)
W02 Transport Protocols for High-Speed Broadband Networks (Douglas J Hoder,
NASA)
Although the Call-for-Paper deadline is March 1st 1996, further details of
the Globecom 96 Technical Programme are available from Professor Hamid
Aghvami, Tel: + 44 171 873 2898, Fax: + 44 171 836 4781, E-mail:
h.aghvami at kcl.ac.uk
CO1 Mini-Conference - Communications Theory
This will consist of 6 Sessions running as a separate stream in parallel
with the Main Sessions from Tuesday 19th to Thursday 21st November.
For further details contact General Chair, F Marvasti at
fam at orion.eee.kcl.ac.uk or for Call for Papers contact the Technical
Programme Chair, Enzin Bigliori at biglieri at polito.it
C02 Mini-Conference - IEEE Global Internet '96
This will consist of Technical Sessions, Panel Sessions, Tutorials, Keynote
Speeches and major player Demonstrations and Exhibits on the subject of the
Internet. The main sessions of the mini-conference are on Wednesday 20th
and Thursday 21st November. If successful, this may be the first of a new
annual IEEE ComSoc Conference on the topic.
For further details contact John Crowcroft at j.crowcroft at cs.ucl.ac.uk
London has of course, many tourist attractions and shopping facilities.
Opposite the Queen Elizabeth II Conference Centre (QEIICC) is Westminster
Abbey with the Houses of Parliament, Whitehall, Trafalgar Square, Buckingham
Palace and St. James s Park all within close walking distance. Globecom 96
have organised a range of tours and social functions. These are:-
SO1-Panoramic London Tour - Monday 18th (am) and Wednesday 20 November (pm)
SO2-St James's Walking Tour - Monday 18th (am)
SO3-Churchill War Rooms - two tours organised for Tuesday 19th November (am
or pm)
SO4-Westminster Abbey - two tours organised for Tuesday 19th November (am or
pm)
SO5-Thames Dinner Cruise - Tuesday 19th November (evening)
SO6-Windsor Castle and Runnymede - Wednesday 20th November (am)
SO7-Stratford-upon-Avon and Oxford - Thursday 21st November (all day)
Three post conference tours to Edinburgh(PO1), Paris(PO2) and Bath(PO3) have
also been organised commencing Friday 22nd to Sunday 24th November.
On Tuesday 19th November there will be an IEEE Awards Luncheon in the QEIICC
and on Wednesday evening (20th November) a Conference Banquet will be held
in the Banqueting Suite of Whitehall Palace which was built in 1620 for King
James 1st of England and Scotland.
Some 1000 bedrooms have been reserved in the area of the QEIICC, all within
10-20 minutes walk or 2-3 stops on the Underground - Circle Line - nearest
stations St. James's Park and Westminster. Prices range from ?30 - ?120 per
night per room.
Heathrow and Gatwick Airports, near London, between them serve more
International Destinations and Passengers than anywhere else. Special
discounted airfares are available from British Airways, when booking through
one of their offices and quoting reference CIC*115/30.
Within London, the network of Tube Trains, Buses and Taxis offer frequent
services to all local destinations.
Fuller, updated information is available via the Globecom '96 WWW homepage,
see:
http://www.labs.bt.com/profsoc/globecom/
If you would like a copy of the Early Registration form faxed to you, please
complete your details below and return via mail, fax or e-mail to Jane
Chopping (as below). Note that a version of the Registration form will
appear on the WWW pages above from mid June '96.
----------------------------------------------------------------------------
----------------------------------------
To: Jane Chopping
IEE Conference Tel: +44 171 344 5469
Savoy Place Fax: +44 171 497 3633
London E-mail: jchopping at iee.org.uk
WC2R 0BL, UK
----------------------------------------------------------------------------
----------------------------------------
FULL NAME AND TITLE:
JOB/POSITION:
COMPANY/UNIVERSITY:
ADDRESS:
CITY/STATE:
POSTCODE/ZIP CODE:
COUNTRY:
TELEPHONE NUMBER:
FAX NUMBER:
E-MAIL ADDRESS:
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12756;
22 Jul 96 13:21 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa10319; 22 Jul 96 13:21 EDT
Received: from ietf.org by ietf.org id aa14716; 22 Jul 96 13:21 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa14648;
22 Jul 96 13:20 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12698;
22 Jul 96 13:20 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10278;
22 Jul 96 13:19 EDT
Received: from mail-d.bcc.ac.uk by venera.isi.edu (5.65c/5.61+local-25)
id <AA29444>; Mon, 22 Jul 1996 10:19:06 -0700
Received: from busby (actually busby.ee.ucl.ac.uk) by mail-d.bcc.ac.uk
with SMTP (PP); Mon, 22 Jul 1996 18:17:19 +0100
Sender:ietf-request at ietf.org
From: a.galis at eleceng.ucl.ac.uk
Received: from [128.40.40.86] (ee-at8th-mac86) by busby;
Mon, 22 Jul 96 18:16:48 BST
X-Sender: agalis at busby
Message-Id: <v02130504ae196e0c69b7 at [128.40.40.86]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 22 Jul 1996 18:18:30 +0000
To: cnom at maestro.bellcore.com, nhe at postman.dg13.cec.be,
announcements.chi at xerox.com, arl at arl.wustl.edu,
arpanet-bboard at mc.lcs.mit.edu, atm at bbn.com,
bcs-hci-request at mailbase.ac.uk, ccrc at dworkin.wustl.edu,
cellular at dfv.rwth-aachen.de, cip at bbn.com, cnom at maestro.bellcore.com,
cybsys-l at bingvmb.cc.binghamton.edu, diagrams at cs.swarthmore.edu,
elsnet-list at cogsci.ed.ac.uk, end2end-interest at isi.edu,
enternet-ec at bbn.com, enternet at bbn.com, f-troup at aurora.cis.upenn.edu,
g-troup at dworkin.wustl.edu, globecom at signet.com.sg,
hipparch at sophia.inria.fr, icad-request at santafe.edu, ie-list at cs.ucl.ac.uk,
ietf at isi.edu, ikbsbb at inf.rl.ac.uk, iplpdn at CNRI.Reston.VA.US, kdd at gte.com,
perform at tay1.dec.com, rem-conf at es.net, sig11 at roses.stanford.edu,
sigmedia at bellcore.com, smds at CNRI.Reston.VA.US, sound at acm.org,
tf-mm at i4serv.informatik.rwth-aachen.de, uist.chi at xerox.com,
visual-l at vtvm1.cc.vt.edu, xtp-relay at cs.concordia.ca,
commsoft at cc.bellcore.com, cnom at maestro.bellcore.com,
utheorynt at vm1.nodak.edu, ietf-announce at CNRI.Reston.VA.US,
sigmedia at bellcore.com, ccrc at dworkin.wustl.edu, ie-list at cs.ucl.ac.uk,
cost237-transport at comp.lancs.ac.uk, arpanet-bboard at mc.lcs.mit.edu,
atm at bbn.com, batnir at agcs.com, klaus.baumer at telekom.dbp.de,
besier at eurescom.d400.de, vab at cc.bellcore.com,
/dd.fax=14079558015/G=Stephen/S=Cannon/ADMD=MCI/C=US/@qmx400gate.nt.com,
laura.cerchio at cselt.stet.it, j.cheong at trl.oz.au, TAIR%TL9000 at nt.com,
cnom at maestro.bellcore.com, Edwin.Frank.Crabill at cbgw1.att.com,
DCrosby at vtrlmel1.trl.oz.au,
/dd.id=ME.Cullum/ADMD=TELECOM.CANADA/C=CA/@qmx400gate.nt.com,
dick.dodd at bridge.bst.bls.com, adoughe at gateway.uswnvg.com,
enternet at bbn.com, javan at comm.toronto.edu,
fulvio.faraci at macpost.cselt.stet.it, igorf at arch4.att.com, rlfike at aol.com,
fogarty at eurescom.d400.de, larryg at arch4.att.com, edgar at tid.es,
geradsd at agcs.com, bur_goode at vnet.ibm.com, gotz at cc.bellcore.com,
epa.epacdh at memo3.ericsson.se, bich at cc.bellcore.com,
epa.epajkj at memo3.ericsson.se, roberto.kung at issy.cnet.fr,
kusaura at krsun.nslab.ntt.jp, hlu at arch4.att.com, kjl at cc.bellcore.com,
ilka at prz.tu-berlin.de, mukasa at ast.lab.kdd.co.jp,
niitsu at krsun.nslab.ntt.jp, oyamada at krsun.nslab.ntt.jp,
etienne.paul at issy.cnet.fr, ieeetcpc at ccvm.sunysb.edu,
swami at cc.bellcore.com, commsoft at cc.bellcore.com,
roberto.saracco at cselt.stet.it, seb at cc.bellcore.com, cjs1 at psp.att.com,
hikaru at kopenews.nslab.ntt.jp, 0002912712 at mcimail.com,
/dd.id=towaij.s/ADMD=TELECOM.CANADA/C=CA/@qmx400gate.nt.com,
brunosv at cpqd.br, waecdb at aur.alcatel.com, Carl. at eleceng.ucl.ac.uk
Source-Info: From (or Sender) name not authenticated.
War at nt.com, comswtc at gmu.edu,
giga at tele.pitt.edu, enternet at bbn.com, ifip-nm at bbn.com,
cnom at maestro.bellcore.com, nmf-members at nmf.com, netmgt at ncri.com,
sig-dsm at doc.imperial.ac.uk, netmgt at ncri.com, enternet at bbn.com,
dsm at nemo.ncsl.nist.gov, nmsig at nemo.ncsl.nist.gov, aow-nmsig at stc.ipa.go.jp,
ewos-egnm at extend.iihe.ac.be, snmsigl at nemo.ncsl.nist.gov,
noms96 at joker.bellcore.com, corpcom at osf.org, nmf-members at nmf.org,
ifip-emailmgt at ics.uci.edu, snmp at psi.com, nadism at mbunix.mitre.org,
mitre-osi at bistromath.mitre.org, nsm-info at gateway.mitre.org,
x3t54 at mbunix.mitre.org, nmsig at ics.uci.edu, rwnmcc at external.iihe.rtt.be,
OSIMIS at cs.ucl.ac.uk, ietf-madman at innosoft.com, nms at netmgrs.co.uk,
iimc at thumper.bellcore.com, OVForum at andrew.cmu.edu,
ieeetcpc at ccvm.sunysb.edu, commsoft at cc.bellcore.com, comswtc at gmu.edu,
isinm97_oc at ctr.columbia.edu,
news.announce.conferences%USENET at maestro.bellcore.com,
ieee.announce at bellcore.com,
comp.protocols.snmp%USENET at maestro.bellcore.com,
comp.protocols.iso at bellcore.com, comp.org.ieee%USENET at maestro.bellcore.com,
barrere at irit.fr, benzekri at irit.fr, bergougn at irit.fr, betourne at irit.fr,
castanet at labri.u-bordeaux.fr, courtiat at laas.fr, cousin at irisa.fr,
diaz at laas.fr, fdida at masi.ibp.fr, filali at irit.fr, fourneau at masi.ibp.fr,
horlait at masi.ibp.fr, jard at irisa.fr, jezequel at irisa.fr, juanole at laas.fr,
mbl at lri.lri.fr, plateau at imag.imag.fr, Guy.Pujolle at prism.uvsq.fr,
rafiq at crisv2.univ-pau.fr, raynal at irisa.fr, raynaud at irit.fr,
trehel at comte.univ-fcomte.fr, hipparch at sophia.inria.fr,
lib at comte.univ-fcomte.fr, prs at uvsq.fr, prs at masi.ibp.fr,
tous.rumeur at lip.ens-lyon.fr, alg at comm.toronto.edu, BM-List1 at cs.ucdavis.edu,
cellular at dfv.rwth-aachen.edu, cnom at maestro.bellcore.com,
comsoc.bog at tab.ieee.org, comsoc-gicb at ieee.org, commsoft at cc.bellcore.com,
comswtc at gmu.edu, cost237-transport at comp.lancs.ac.uk,
ctc-members at redbank.tinac.com, enternet at bbn.com,
forte at informatik.uni-kl.de, gcomlist1 at manjaro.ece.iit.edu,
giga at tele.pitt.edu, ieeetcpc at ccvm.sunysb.edu, ieee_rtc_list at cs.tamu.edu,
isadsoc at fokus.gmd.de, modern-heuristics at uk.ac.mailbase.ucdavis.edu,
multicomm at cc.bellcore.com, osimcast at bbn.com, reres at comm.polymtl.ca,
reres at uklirb.informatik.uni-kl.de, sc6wg4 at ntd.comsat.com,
sigmedia at bellcore.com, tccc at cs.umass.edu, testnet at canarie.ca,
xtp-relay at cs.concordia.ca
From: a.galis (Alex Galis)
Subject: GLOBCOM'96 - London U.K. / 18-22 November 1996
Cc: a.galis at busby, c.todd at busby
Dear All,
In the name of the Organising Committee I am pleased to invite you to
attend GLOBCOM'96 Telecommunications Conference organised by IEEE in London
( 18th - 22nd November 1996).
Yours sincerely
Alex Galis
University College London
............................................................................
...........................
1996 IEEE GLOBAL TELECOMMUNICATIONS CONFERENCE
18th - 22nd November 1996
Queen Elizabeth II Conference Centre, Westminster, London
"Communications: The Key to Global Prosperity"
This major international communications conference, held annually for some
25 years, is to be hosted in London for its first staging in Europe.
Sponsored by the IEEE Communications Society and in conjunction with the
IEE, Globecom 96 aims to attract 1000+ of the leading telecommunication
development engineers, academics, operators and manufacturers from all parts
of the world.
The Conference will consist of 50 Technical Sessions (in 9 parallel tracks),
6 Sessions of a Mini-Conference on Communications Theory, 4 Sessions of a
Mini-Conference called "IEEE Global Internet '96" and 4 Panel Session
discussions on key Business Topics over the 3 days (Tuesday 19th, Wednesday
20th and Thursday 21st November 1996). On Monday 18th and Friday 22nd
November there will be some 27 half-day equivalent sessions devoted to
Tutorials and Workshops on key Hot Topics. Throughout the week there will
be a 20 stand Exhibition of sponsoring companies, publishers and future
ComSoc Conferences. In addition there will be a separate Exhibition on
Internet and related telecomms topics.
Hot Topics
The Hot Topics below have been identified by the ComSoc Technical
Committees. These titles have been accepted by the Globecom '96 Technical
Programme Committee as forming a basis on which to assemble Technical
Session and Tutorials etc.
- Advances in PCS
- Wireless ATM
- Advanced switching architectures for broadband networks
- Network issues in wireless communications
- Distributed Software Challenges
- Software Support for Interactive MultiMedia Services and Applications
- Wireless Communication and ATM
- Towards ATM Switching Systems with Terabit/s Capacity
- Signal Processing for Multimedia Services
- Advanced VLSI Signal Processing in Communications
- Quality of service for advanced communication services (PCS, Multimedia,
Internet)
- Software engineering technologies and experience to Improve and sustain
network quality objectives
- Mobile Satellite Communications
- Satellite Communications for Broadband Networks
- Security and Privacy in the GII/NII
- Multicasting
- Multimedia over the Internet
- Interactive Video Applications and Supporting Technologies
- Optical Access Networks and New Services Development
- Very High-Speed ( OC-192) Optical Transmission
Panel Sessions
These will consist of short presentations followed by discussion, lead by a
group of the leading Global Players on the Topics of:-
1. Visions of the 21st Century
2. Wireless revolution towards global roaming
3. The Information highway - market and service provider perspectives
4. Service and quality: customer's perceptions
Tutorials and Workshops - mixture of full and half day Sessions
The titles and leaders are:
Monday tutorials and workshop
T01 Telecommunications Management Network:- Standards, Implementation and
Applications (Veli Sahin, NEC America Inc)
T02 Introduction to ATM (Khosrow Sohraby, IBM)
T03 GSM - Recent Advances and Future Developments (Paul Kakaes, Cosmos
Communications Consulting)
T04 Traffic Modelling and Management in Wireless Communications Systems
(am) (Sirin Tekinay, Bell Northern Research)
T05 Modelling and Transmission issues for VBR video over B-ISDN Networks
(am) (Dr Ghanbari, University of Essex)
T06 High Speed Wireless Data (Len Cimini, AT&T Bell Laboratories and Andrea
Goldsmith, California Institute of Technology)
T07 JAVA (Prof John N Daigle)
T08 The Intelligent Network and Mobile System Control (pm) (Prof Bijan
Jabbari, George Mason University)
T09 Iterative Turbo-Decoding (pm) (Joachim Hagenauer, TU Munich)
T10 Interactive Multimedia over the Internet (pm) (Mark Handley and Ian
Wakemen, UCL and Sussex University)
W01 Very-high-speed Digital Subscriber Lines (Prof John M Cioffi, Stanford
University)
Friday tutorials and workshop
T11 Mobile and Multimedia Satellite Systems (Dr K M S Murthy, VISTAR
Telecommunications)
T12 Spread Spectrum Systems for PCS (Elvino S Sousa, University of Toronto)
T13 Mobility Management in TCP/IP Networks (Dr Zygmunt Haas, Cornell
University)
T14 Operation and Management of Multi-Wavelength Optical Networks (am) (Dr
Mari Maeda, Bell Communications Research)
T15 Internet IP Security (am) ( Ran Atkinson, Internet Security)
T16 Adaptive Antennas for Wireless Systems (pm) (Jack Winters, AT&T Bell
Laboratories)
T17 IP and ATM - Enterprise Internetworking (pm) (David Ginsburg, CISCO
Corp)
W02 Transport Protocols for High-Speed Broadband Networks (Douglas J Hoder,
NASA)
Although the Call-for-Paper deadline is March 1st 1996, further details of
the Globecom 96 Technical Programme are available from Professor Hamid
Aghvami, Tel: + 44 171 873 2898, Fax: + 44 171 836 4781, E-mail:
h.aghvami at kcl.ac.uk
CO1 Mini-Conference - Communications Theory
This will consist of 6 Sessions running as a separate stream in parallel
with the Main Sessions from Tuesday 19th to Thursday 21st November.
For further details contact General Chair, F Marvasti at
fam at orion.eee.kcl.ac.uk or for Call for Papers contact the Technical
Programme Chair, Enzin Bigliori at biglieri at polito.it
C02 Mini-Conference - IEEE Global Internet '96
This will consist of Technical Sessions, Panel Sessions, Tutorials, Keynote
Speeches and major player Demonstrations and Exhibits on the subject of the
Internet. The main sessions of the mini-conference are on Wednesday 20th
and Thursday 21st November. If successful, this may be the first of a new
annual IEEE ComSoc Conference on the topic.
For further details contact John Crowcroft at j.crowcroft at cs.ucl.ac.uk
London has of course, many tourist attractions and shopping facilities.
Opposite the Queen Elizabeth II Conference Centre (QEIICC) is Westminster
Abbey with the Houses of Parliament, Whitehall, Trafalgar Square, Buckingham
Palace and St. James s Park all within close walking distance. Globecom 96
have organised a range of tours and social functions. These are:-
SO1-Panoramic London Tour - Monday 18th (am) and Wednesday 20 November (pm)
SO2-St James's Walking Tour - Monday 18th (am)
SO3-Churchill War Rooms - two tours organised for Tuesday 19th November (am
or pm)
SO4-Westminster Abbey - two tours organised for Tuesday 19th November (am or
pm)
SO5-Thames Dinner Cruise - Tuesday 19th November (evening)
SO6-Windsor Castle and Runnymede - Wednesday 20th November (am)
SO7-Stratford-upon-Avon and Oxford - Thursday 21st November (all day)
Three post conference tours to Edinburgh(PO1), Paris(PO2) and Bath(PO3) have
also been organised commencing Friday 22nd to Sunday 24th November.
On Tuesday 19th November there will be an IEEE Awards Luncheon in the QEIICC
and on Wednesday evening (20th November) a Conference Banquet will be held
in the Banqueting Suite of Whitehall Palace which was built in 1620 for King
James 1st of England and Scotland.
Some 1000 bedrooms have been reserved in the area of the QEIICC, all within
10-20 minutes walk or 2-3 stops on the Underground - Circle Line - nearest
stations St. James's Park and Westminster. Prices range from ?30 - ?120 per
night per room.
Heathrow and Gatwick Airports, near London, between them serve more
International Destinations and Passengers than anywhere else. Special
discounted airfares are available from British Airways, when booking through
one of their offices and quoting reference CIC*115/30.
Within London, the network of Tube Trains, Buses and Taxis offer frequent
services to all local destinations.
Fuller, updated information is available via the Globecom '96 WWW homepage,
see:
http://www.labs.bt.com/profsoc/globecom/
If you would like a copy of the Early Registration form faxed to you, please
complete your details below and return via mail, fax or e-mail to Jane
Chopping (as below). Note that a version of the Registration form will
appear on the WWW pages above from mid June '96.
----------------------------------------------------------------------------
----------------------------------------
To: Jane Chopping
IEE Conference Tel: +44 171 344 5469
Savoy Place Fax: +44 171 497 3633
London E-mail: jchopping at iee.org.uk
WC2R 0BL, UK
----------------------------------------------------------------------------
----------------------------------------
FULL NAME AND TITLE:
JOB/POSITION:
COMPANY/UNIVERSITY:
ADDRESS:
CITY/STATE:
POSTCODE/ZIP CODE:
COUNTRY:
TELEPHONE NUMBER:
FAX NUMBER:
E-MAIL ADDRESS:
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15208;
22 Jul 96 16:40 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa13555; 22 Jul 96 16:40 EDT
Received: from ietf.org by ietf.org id aa01229; 22 Jul 96 16:40 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa01102;
22 Jul 96 16:36 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15145;
22 Jul 96 16:36 EDT
Received: from general.ulcc.ac.uk by CNRI.Reston.VA.US id aa13470;
22 Jul 96 16:36 EDT
Received: from gunnar (actually host ezna048.ds.ulcc.ac.uk)
by general.ulcc.ac.uk with SMTP (PP); Mon, 22 Jul 1996 21:36:23 +0100
Received: by gunnar with Microsoft Mailid <01BB7815.985E8C00 at gunnar>;
Mon, 22 Jul 1996 21:34:42 +-100
Message-ID: <01BB7815.985E8C00 at gunnar>
Sender:ietf-request at ietf.org
From: Peter Furniss <p.furniss at ulcc.ac.uk>
To: 'Dave Crocker' <dcrocker at brandenburg.com>
Cc: "ietf at CNRI.Reston.VA.US" <ietf at CNRI.Reston.VA.US>
Subject: RE: Last Call: TCP Slow Start, Congestion Avoidance, Fast Retransmit,
and Fast Recovery Algorithms
Date: Mon, 22 Jul 1996 13:36:13 +-100
Encoding: 44 TEXT
Source-Info: From (or Sender) name not authenticated.
Dave Crocker sent :
> >The "right" fix is to move this quota out of the listen queue and into
some
>
>I've had the usual reaction to the conspicuous consumption of the
> current Netscape behavior, but I've also noticed that having the screen
> fill in by several different images, rather than doing all of one first,
is
> pretty nice.
>
>This makes me think that the web's use of tcp needs to have an
> old-time "session" layer above it, for multiple data streams. Nothing as
> heavy weight as the OSI stuff, of course, but a basic way of segmenting
the
> data stream. (It would help FTP, too, since it would eliminate the mess
of
> running FTP through firewalls.) Ah well, fantasizes modifications to the
> infrastructure is always fun.
Curiously enough, there are a set of amendments proposed for OSI session
which would do precisely this, allowing "nested connections", where there
are several session connections, all travelling on one transport
connection. They are logically nested, so the termination of one will
terminate the connections inside it, but not those outside. In the
protocol, each connection is identified by a single (low) number, so the
heavyweightness of this feature is 3 bytes.
The facitility can be offered on any connection establishment (for the
first, would-be outermost session connection) - if accepted, good; if not
recognised, use separate T-connections. The negotiation is more
heavy-weight of course (but, for session, not much)
Peter
Peter Furniss Consultants
58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK
Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy)
Email : P.Furniss at ulcc.ac.uk
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16539;
22 Jul 96 18:34 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa15677; 22 Jul 96 18:34 EDT
Received: from ietf.org by ietf.org id aa03836; 22 Jul 96 18:33 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa03767;
22 Jul 96 18:31 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16506;
22 Jul 96 18:31 EDT
Received: from ng.netgate.net by CNRI.Reston.VA.US id aa15612;
22 Jul 96 18:31 EDT
Received: from [205.214.160.46] (d17.netgate.net [205.214.160.49]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id PAA00817; Mon, 22 Jul 1996 15:37:54 -0700 (PDT)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v03007804ae19a0fceeb9 at [205.214.160.46]>
In-Reply-To: <01BB7815.985E8C00 at gunnar>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Mon, 22 Jul 1996 14:20:29 -0700
To: Peter Furniss <p.furniss at ulcc.ac.uk>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: RE: Last Call: TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms
Cc: "ietf at CNRI.Reston.VA.US" <ietf at CNRI.Reston.VA.US>
Source-Info: From (or Sender) name not authenticated.
At 6:36 AM -0700 7/22/96, Peter Furniss wrote:
>Curiously enough, there are a set of amendments proposed for OSI session
I hope I was clear in my earlier note that I was NOT recommending
the specific OSI session layer. Too much overhead. Something VERY
lightweight is all that's needed.
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06908;
23 Jul 96 4:35 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa03660; 23 Jul 96 4:35 EDT
Received: from ietf.org by ietf.org id aa15012; 23 Jul 96 4:35 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa14948; 23 Jul 96 4:27 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06877;
23 Jul 96 4:27 EDT
Received: from [131.112.32.132] by CNRI.Reston.VA.US id aa03583;
23 Jul 96 4:27 EDT
Sender:ietf-request at ietf.org
From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Message-Id: <199607230827.RAA08401 at necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
id RAA08401; Tue, 23 Jul 1996 17:27:14 +0900
Subject: Re: Last Call: TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms
To: Paul A Vixie <paul at vix.com>
Date: Tue, 23 Jul 96 17:27:13 JST
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <VIXIE.96Jul21004748 at wisdom.vix.com>; from "Paul A Vixie" at Jul 21, 96 12:47 am
X-Mailer: ELM [version 2.3 PL11]
Source-Info: From (or Sender) name not authenticated.
> This sounds like the httpd hack I did a while back that rejects concurrent
> connections from the same host, thus defeating Netscape's odd habit of opening
> lots of simultaneous HTTP connections to the same place at the same time "to
> get better service."
I'm afraid it will only encourage someone develop an implementation
of IP on PC with multiple source addresses.
Masataka Ohta
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07291;
23 Jul 96 5:55 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa04385; 23 Jul 96 5:55 EDT
Received: from ietf.org by ietf.org id aa15717; 23 Jul 96 5:55 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa15650; 23 Jul 96 5:51 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07273;
23 Jul 96 5:51 EDT
Received: from bells.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa04352;
23 Jul 96 5:51 EDT
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.07475-0 at bells.cs.ucl.ac.uk>; Tue, 23 Jul 1996 10:41:29 +0100
To: Paul A Vixie <paul at vix.com>, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: TCP Slow Start, Congestion Avoidance, Fast Retransmit,
and Fast Recovery Algorithms
In-reply-to: Your message of "Tue, 23 Jul 1996 17:27:13 +0200." <199607230827.RAA08401 at necom830.hpcl.titech.ac.jp>
Date: Tue, 23 Jul 1996 10:41:23 +0100
Message-ID: <1233.838114883 at cs.ucl.ac.uk>
Sender:ietf-request at ietf.org
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Source-Info: From (or Sender) name not authenticated.
>> This sounds like the httpd hack I did a while back that rejects concurrent
>> connections from the same host, thus defeating Netscape's odd habit of opening
>> lots of simultaneous HTTP connections to the same place at the same time "to
>> get better service."
>I'm afraid it will only encourage someone develop an implementation
>of IP on PC with multiple source addresses.
if they could support multiple addresses and dynamic assignment at low
cost, this would suit a HUGE number of other requirements
(renumbering, not the least....)
what most multiple address hacks do in practice though is to allow
multiple host addreses on the same IP net/.prefix...
actually, what is needed is
a) renumbering by prefix to solve ipng and ipv4 renumbering problems
b) policing/pricing/dropping of traffic by source/destination prefix
to solve http traffic load problems....
jon
Received: from cnri by ietf.org id aa07463; 24 Jul 96 11:55 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa09313; 24 Jul 96 11:55 EDT
Received: from ietf.org by ietf.org id aa07455; 24 Jul 96 11:55 EDT
Received: from pilot.is.chrysler.com by ietf.org id aa07361; 24 Jul 96 11:53 EDT
Received: by pilot.firewall.is.chrysler.com; id LAA04105; Wed, 24 Jul 1996 11:53:25 -0400
Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilot.is.chrysler.com via smap (g3.0.1)
id sma004102; Wed, 24 Jul 96 11:53:03 -0400
Received: from rgm3 by mhbclpr2-nf0.is.chrysler.com (8.7.5/SMI-4.1)
id LAA04572; Wed, 24 Jul 1996 11:46:29 -0400 (EDT)
Message-Id: <2.2.32.19960724155236.00bf7260 at pop3hub.is.chrysler.com>
X-Sender: t3125rm at pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 24 Jul 1996 11:52:36 -0400
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Multipart/Related in use anyway?
Source-Info: From (or Sender) name not authenticated.
Is Multipart/Related (RFC 1872) in use anyway?
I would like to see how it has been used, or what alternatives there are, I
am working on an item that has a minimum of 2 parts that must always be
worked with together. Convention can handle it, but....
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from cnri by ietf.org id aa09647; 24 Jul 96 13:08 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa10407; 24 Jul 96 13:08 EDT
Received: from ietf.org by ietf.org id aa09638; 24 Jul 96 13:08 EDT
Received: from cnri by ietf.org id aa09577; 24 Jul 96 13:05 EDT
Received: from clmex600.atsc.allied.com by CNRI.Reston.VA.US id aa10373;
24 Jul 96 13:05 EDT
Received: by clmex600.atsc.allied.com with Microsoft Exchange (IMC 4.0.837.3)
id <01BB7961.1C846D50 at clmex600.atsc.allied.com>; Wed, 24 Jul 1996 13:07:48 -0400
Message-ID: <c=US%a=_%p=AlliedSignal%l=CLMEX600-960724170746Z-674 at clmex600.atsc.allied.com>
Sender:ietf-request at ietf.org
From: "Markle, David W." <david.w.markle at atsc.allied.com>
To: 'Alan Hannan' <alan at gi.net>
Cc: "'mclark at tribune.com'" <mclark at tribune.com>,
"'rory at carmelnet.com'" <rory at carmelnet.com>,
"'ietf at CNRI.Reston.VA.US'" <ietf at CNRI.Reston.VA.US>
Subject: RE: CIA snooping the net
Date: Wed, 24 Jul 1996 13:07:46 -0400
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Why do you think PGP was difficult to get for that brief period when it
first became available on the net. NSA.
-dm
>----------
>From:Alan Hannan[SMTP:alan at gi.net]
>Sent:Tuesday, July 23, 1996 5:07 PM
>To:Phil Karn
>Cc:mclark at tribune.com; rory at carmelnet.com; ietf at CNRI.Reston.VA.US
>Subject:Re: CIA snooping the net
>
>
> Yeah, no chance of the CIA decrypting PGP if they wanted to.
>
> (friendly sarcasm off :-)
>
> -alan
>
>......... Phil Karn is rumored to have said:
>]
>] >E-mail is not privileged material. However, it is currently under
>] >review by the Supreme Court in re Wang. Anyone got anymore info?
>]
>] Well, one good way to make it an academic issue is to encrypt with
>] PGP. And use tools like ssh for remote access and file transfer.
>]
>] Phil
>]
>
>
Received: from cnri by ietf.org id aa11257; 24 Jul 96 14:17 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa11439; 24 Jul 96 14:17 EDT
Received: from ietf.org by ietf.org id aa11230; 24 Jul 96 14:17 EDT
Received: from kroma.eit.com by ietf.org id aa11138; 24 Jul 96 14:14 EDT
Received: from clue.eit.com (clue.eit.com [207.90.129.31]) by eit.com (8.7.5/8.7.3) with SMTP id LAA08227; Wed, 24 Jul 1996 11:14:05 -0700 (PDT)
Message-Id: <2.2.32.19960724180314.00c744a4 at pop.eit.com>
X-Sender: ali at pop.eit.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 24 Jul 1996 11:03:14 -0700
To: Robert Moskowitz <rgm3 at chrysler.com>, ietf at ietf.org
Sender:ietf-request at ietf.org
From: Alireza Bahreman <bahreman at eit.com>
Subject: Re: Multipart/Related in use anyway?
Source-Info: From (or Sender) name not authenticated.
At 11:52 AM 7/24/96 -0400, Robert Moskowitz wrote:
>Is Multipart/Related (RFC 1872) in use anyway?
There is a use for it. One has been suggested in the
"draft-bahreman-mapplet-spec-00.txt". This deals with MIME encapsulation of
aggregate applet objects. We have an implementation at the E-CO System project.
Regards,
Alireza Bahreman
Project Leader,
EIT/Internet Commerce Division, VeriFone
bahreman at eit.com
(415) 617-8797
(415) 617-8019 FAX
Received: from cnri by ietf.org id aa12359; 24 Jul 96 14:39 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa11813; 24 Jul 96 14:39 EDT
Received: from ietf.org by ietf.org id aa12342; 24 Jul 96 14:39 EDT
Received: from cnri by ietf.org id aa12169; 24 Jul 96 14:38 EDT
Received: from [198.186.46.233] by CNRI.Reston.VA.US id aa11786;
24 Jul 96 14:38 EDT
Received: by clmex600.atsc.allied.com with Microsoft Exchange (IMC 4.0.837.3)
id <01BB796D.FC3812B0 at clmex600.atsc.allied.com>; Wed, 24 Jul 1996 14:39:57 -0400
Message-ID: <c=US%a=_%p=AlliedSignal%l=CLMEX600-960724183955Z-685 at clmex600.atsc.allied.com>
Sender:ietf-request at ietf.org
From: "Markle, David W." <david.w.markle at atsc.allied.com>
To: 'Fred Baker' <fred at cisco.com>
Cc: "'ietf at CNRI.Reston.VA.US'" <ietf at CNRI.Reston.VA.US>
Subject: RE: CIA snooping the net
Date: Wed, 24 Jul 1996 14:39:55 -0400
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Don't think the CIA is doing anything?????? Check out the excerpt from
Feb 96 WIRED (p.72):
"Spies at the Gate"
-- by Stephen Pizzo --
"An all-star cast of shady characters now controls the Net's domain
name system.
On September 18, the National Science Foundation and its private
sector contractor, Network Solutions Inc., announced that effective
immediately, all Internet domain name registrations better arrive with a
US$50 check attached. With that decision, InterNic, the Internet's
official domain name registry run by Network Solutions, instantly became
a self-funding, private enterprise. Finally, the last vestige of
government control was removed from the Net.
Or was it? As it turns out, Network Solutions had been quietly
purchased by Science Applications International Corp. (SAIC) just weeks
before the new fee system was announced. SAIC is a $2 billion-a-year
defense contractor that derives more than 90 percent of its income from
contracts with US military, law enforcement, and intelligence agencies.
SAIC's board of directors reads like a who's who of government
spookery: former NSA chief and deputy director of the CIA Bobby Inman
and former Nixon Defense Secretary Melvin Laird sit on SAIC's board. In
addition, there's retired general Max Thurman, who commanded US troops
during the invasion of Panama; Don Hicks, a former head of R&D for the
Pentagon; and Don Kerr, former head of the Los Alamos National
Laboratory. Until recently, the board also included former CIA Director
Robert Gates, current CIA Director John Deutch, and current Defense
Secretary William Perry.
SAIC bristles at the implication that the InterNic contract is a
Trojan horse for Net surveillance. But to remove all doubt, the National
Science Foundation should reclaim the top-level .com, .org, .net, and
.edu domains and hand them over as a public trust to a group such as the
Internet Society. Then leave SAIC to maintain the .gov and .mil domains.
In fact, they might consider creating a new top-level domain just
for government contractors - .pork comes to mind. "
CHECK OUT FOR YOURSELVES:
http://www.hotwired.com/wired/4.02/cyber.rights.html
-dm
David.W.Markle at ATSC.Allied.com
>----------
>From:Fred Baker[SMTP:fred at cisco.com]
>Sent:Tuesday, July 23, 1996 4:14 PM
>To:rory at carmelnet.com
>Cc:ietf at CNRI.Reston.VA.US
>Subject:Re:CIA snooping the net
>
>At 8:32 AM 7/23/96, Rory Sellers spluttered:
>> Is this an open admission that the CIA thinks it is legal to monitor any
>> and all Internet traffic. Can they legally read all email?
>
>There are a couple of places on the net where folks pick up traffic and
>save a sanitized version for traffic analysis - look at
>http://www.nlanr.net for such. They do not capture data content, and
>they
>won't even give you the actual addresses of the traffic - they first
>run a
>replacement algorithm so that the small amount of information captured
>(IP
>Address From/To, Protocol, UDP/TCP Ports if applicable, length, and a
>time
>stamp) is completely anonymous.
>
>It isn't the CIA that's doing that, it's the research community. And
>getting even that level of access is like pulling teeth - most
>providers
>simply will not allow them in.
>
>No, I don't think the CIA is sniffing the net. That would require
>access
>that even they simply don't have.
>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>=-=
>I don't suffer from insanity. I enjoy every minute of it.
>
>
>
Received: from ietf.org by ietf.org id aa04659; 25 Jul 96 9:33 EDT
Received: from localhost by ietf.org id aa04139; 25 Jul 96 9:20 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-pppext-eap-auth-02.txt
Date: Thu, 25 Jul 1996 09:20:41 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607250920.aa04139 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : PPP Extensible Authentication Protocol (EAP)
Author(s) : L. Blunk, J. Vollbrecht
Filename : draft-ietf-pppext-eap-auth-02.txt
Pages : 18
Date : 07/23/1996
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
PPP also defines an extensible Link Control Protocol, which allows
negotiation of an Authentication Protocol for authenticating its peer
before allowing Network Layer protocols to transmit over the link.
This document defines the PPP Extensible Authentication Protocol.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pppext-eap-auth-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-eap-auth-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-eap-auth-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960724162722.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-eap-auth-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-eap-auth-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960724162722.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04661; 25 Jul 96 9:33 EDT
Received: from localhost by ietf.org id aa04118; 25 Jul 96 9:20 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: oncrpc-wg at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-oncrpc-rpcsec_gss-00.txt
Date: Thu, 25 Jul 1996 09:20:31 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607250920.aa04118 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the ONC Remote Procedure Call
Working Group of the IETF.
Title : RPCSEC_GSS Protocol Specification
Author(s) : M. Eisler, A. Chiu, L. Ling
Filename : draft-ietf-oncrpc-rpcsec_gss-00.txt
Pages : 22
Date : 07/24/1996
This memo describes an ONC/RPC security flavor that allows RPC protocols to
access the Generic Security Services Application Programming Interface
(referred to henceforth as GSS-API).
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-oncrpc-rpcsec_gss-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-oncrpc-rpcsec_gss-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-oncrpc-rpcsec_gss-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960724161438.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-oncrpc-rpcsec_gss-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-oncrpc-rpcsec_gss-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960724161438.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04658; 25 Jul 96 9:33 EDT
Received: from localhost by ietf.org id aa04083; 25 Jul 96 9:20 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-armitage-ion-venus-00.txt
Date: Thu, 25 Jul 1996 09:20:10 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607250920.aa04083 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : VENUS - Very Extensive Non-Unicast Service
Author(s) : G. Armitage
Filename : draft-armitage-ion-venus-00.txt
Pages : 12
Date : 07/24/1996
The MARS model is our current solution to IP multicasting over ATM,
establishing and managing the use of ATM pt-mpt SVCs for intra-LIS IP
multicast packet forwarding. Inter-LIS multicast forwarding is achieved
using Mrouters, in a similar manner to which the `Classical IP over ATM'
model uses Routers to inter-connect LISes for unicast traffic. The
development of unicast IP `cut-through' mechanisms (e.g. NHRP) has led some
people to request the development of a Multicast equivalent. This document
describes a hypothetical solution, dubbed `Very Extensive NonUnicast
Service' (VENUS), shows how complex such a service would be, and asserts
that analogies with unicast cut-through mechanisms are not entirely
appropriate. It is also noted that VENUS ultimately has the look and feel
of a single, large cluster using a distributed MARS - a problem space we
are already tackling for other reasons. This document is being issued to
help focus ION efforts, and optionally challenge people to prove its
thesis wrong.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-armitage-ion-venus-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-armitage-ion-venus-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-armitage-ion-venus-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960724160829.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-armitage-ion-venus-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-armitage-ion-venus-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960724160829.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04655; 25 Jul 96 9:33 EDT
Received: from localhost by ietf.org id aa04107; 25 Jul 96 9:20 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-gellens-telnet-char-option-03.txt, .ps
Date: Thu, 25 Jul 1996 09:20:38 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607250920.aa04107 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : TELNET CHARSET Option
Author(s) : R. Gellens
Filename : draft-gellens-telnet-char-option-03.txt, .ps
Pages : 16
Date : 07/24/1996
This document specifies a mechanism for passing character set and
translation information between a TELNET client and server. Use of this
mechanism enables an application used by a TELNET user to send and receive
data in the correct character set.
Either side can (subject to option negotiation) at any time request
that a (new) character set be used.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-gellens-telnet-char-option-03.txt".
Or
"get draft-gellens-telnet-char-option-03.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-gellens-telnet-char-option-03.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-gellens-telnet-char-option-03.txt".
Or
"FILE /internet-drafts/draft-gellens-telnet-char-option-03.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960724162008.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-gellens-telnet-char-option-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-gellens-telnet-char-option-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960724162008.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05499; 25 Jul 96 9:48 EDT
Received: from cnri by ietf.org id aa05378; 25 Jul 96 9:45 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa06717;
25 Jul 96 9:45 EDT
Received: from gpo.cc.bellcore.com by venera.isi.edu (5.65c/5.61+local-25)
id <AA11375>; Thu, 25 Jul 1996 06:45:39 -0700
Received: from itc.cc.bellcore.com by gpo.cc.bellcore.com with SMTP id AA20197
(5.67b/IDA-1.5); Thu, 25 Jul 1996 08:07:37 -0400
Received: from cc:Mail by itc.cc.bellcore.com
id AA838307186 Thu, 25 Jul 96 08:06:26 EDT
Date: Thu, 25 Jul 96 08:06:26 EDT
Sender:ietf-request at ietf.org
From: shh <shh at itc.cc.bellcore.com>
Message-Id: <9606258383.AA838307186 at itc.cc.bellcore.com>
To: a.galis at eleceng.ucl.ac.uk, cnom at maestro.bellcore.com,
nhe at postman.dg13.cec.be, announcements.chi at xerox.com, arl at arl.wustl.edu,
arpanet-bboard at mc.lcs.mit.edu, atm at bbn.com,
bcs-hci-request at mailbase.ac.uk, ccrc at dworkin.wustl.edu,
cellular at dfv.rwth-aachen.de, cip at bbn.com,
cybsys-l at bingvmb.cc.binghamton.edu, diagrams at cs.swarthmore.edu,
elsnet-list at cogsci.ed.ac.uk, end2end-interest at isi.edu,
enternet-ec at bbn.com, enternet at bbn.com, f-troup at aurora.cis.upenn.edu,
g-troup at dworkin.wustl.edu, globecom at signet.com.sg,
hipparch at sophia.inria.fr, icad-request at santafe.edu, ie-list at cs.ucl.ac.uk,
ietf at isi.edu, ikbsbb at inf.rl.ac.uk, iplpdn at CNRI.Reston.VA.US, kdd at gte.com,
perform at tay1.dec.com, rem-conf at es.net, sig11 at roses.stanford.edu,
sigmedia at bellcore.com, smds at CNRI.Reston.VA.US, sound at acm.org,
tf-mm at i4serv.informatik.rwth-aachen.de, uist.chi at xerox.com,
visual-l at vtvm1.cc.vt.edu, xtp-relay at cs.concordia.ca,
commsoft at cc.bellcore.com, utheorynt at vm1.nodak.edu,
ietf-announce at CNRI.Reston.VA.US, cost237-transport at comp.lancs.ac.uk,
batnir at agcs.com, klaus.baumer at telekom.dbp.de, besier at eurescom.d400.de,
vab at cc.bellcore.com,
/dd.fax=14079558015/G=Stephen/S=Cannon/ADMD=MCI/C=US/@qmx400gate.nt.com,
laura.cerchio at cselt.stet.it, j.cheong at trl.oz.au, TAIR%TL9000 at nt.com,
Edwin.Frank.Crabill at cbgw1.att.com, DCrosby at vtrlmel1.trl.oz.au,
/dd.id=ME.Cullum/ADMD=TELECOM.CANADA/C=CA/@qmx400gate.nt.com,
dick.dodd at bridge.bst.bls.com, adoughe at gateway.uswnvg.com,
javan at comm.toronto.edu, fulvio.faraci at macpost.cselt.stet.it,
igorf at arch4.att.com, rlfike at aol.com, fogarty at eurescom.d400.de,
larryg at arch4.att.com, edgar at tid.es, geradsd at agcs.com,
bur_goode at vnet.ibm.com, gotz at cc.bellcore.com,
epa.epacdh at memo3.ericsson.se, bich at cc.bellcore.com,
epa.epajkj at memo3.ericsson.se, roberto.kung at issy.cnet.fr,
kusaura at krsun.nslab.ntt.jp, hlu at arch4.att.com, kjl at cc.bellcore.com,
ilka at prz.tu-berlin.de, mukasa at ast.lab.kdd.co.jp,
niitsu at krsun.nslab.ntt.jp, oyamada at krsun.nslab.ntt.jp,
etienne.paul at issy.cnet.fr, ieeetcpc at ccvm.sunysb.edu,
swami at cc.bellcore.com, roberto.saracco at cselt.stet.it, seb at cc.bellcore.com,
cjs1 at psp.att.com, hikaru at kopenews.nslab.ntt.jp, 0002912712 at mcimail.com,
/dd.id=towaij.s/ADMD=TELECOM.CANADA/C=CA/@qmx400gate.nt.com,
brunosv at cpqd.br, waecdb at aur.alcatel.com, Carl. at eleceng.ucl.ac.uk
Subject: Re:
Source-Info: From (or Sender) name not authenticated.
Received: from ietf.org by ietf.org id aa07641; 25 Jul 96 10:55 EDT
Received: from tank.cyberphile.co.uk by ietf.org id aa07582; 25 Jul 96 10:54 EDT
Received: from blaze_m04.cyberphile.co.uk (blaze_m06.cyberphile.co.uk) by
tank.cyberphile.co.uk (MX V4.0-1 VAX) with SMTP; Thu, 25 Jul 1996
15:53:28 EDT
Received: by blaze_m04.cyberphile.co.uk with Microsoft Mail id
<01BB7A41.31C3D080 at blaze_m04.cyberphile.co.uk>; Thu, 25 Jul 1996
15:51:50 +-100
Message-ID: <01BB7A41.31C3D080 at blaze_m04.cyberphile.co.uk>
Sender:ietf-request at ietf.org
From: Dominic Cooper <dcooper at cyberphile.co.uk>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject:
Date: Thu, 25 Jul 1996 15:51:43 +-100
Return-Receipt-To: <dcooper at cyberphile.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
unsubscribe
Received: from ietf.org by ietf.org id aa10452; 25 Jul 96 12:21 EDT
Received: from glaucus.cso.uiuc.edu by ietf.org id aa10352; 25 Jul 96 12:19 EDT
Received: from resnick1.isdn.uiuc.edu by glaucus.cso.uiuc.edu (AIX 3.2/UCB 5.64/4.03)
id AA08218; Thu, 25 Jul 1996 11:16:13 -0500
X-Sender: resnick at glaucus.cso.uiuc.edu
Message-Id: <v03007806ae1d4eba869d at ra4000-p26.qualcomm.com>
In-Reply-To: <2.2.32.19960724155236.00bf7260 at pop3hub.is.chrysler.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Eudora [Macintosh version 3.0]
Date: Thu, 25 Jul 1996 11:18:16 -0500
To: Robert Moskowitz <rgm3 at chrysler.com>
Sender:ietf-request at ietf.org
From: Pete Resnick <presnick at qualcomm.com>
Subject: Re: Multipart/Related in use anyway?
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
On 7/24/96 at 10:52 AM -0500, Robert Moskowitz wrote:
>Is Multipart/Related (RFC 1872) in use anyway?
>
>I would like to see how it has been used, or what alternatives there are, I
>am working on an item that has a minimum of 2 parts that must always be
>worked with together. Convention can handle it, but....
The MHTML working group has commandeered it and is planning to get it on
the standards track. See what's going on over there.
pr
--
Pete Resnick <mailto:presnick at qualcomm.com>
QUALCOMM Incorporated
Received: from ietf.org by ietf.org id aa14232; 25 Jul 96 15:23 EDT
Received: from zaphod.axion.bt.co.uk by ietf.org id aa14152; 25 Jul 96 15:20 EDT
Received: from bt-web.bt.co.uk by zaphod.axion.bt.co.uk via DECnet inbound channel id <sg.04934-0 at zaphod.axion.bt.co.uk>;
Thu, 25 Jul 1996 20:19:46 +0100
X-Vms-To: R11F::IETF.ORG::IETF
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: smith_k_kevin at bt-web.bt.co.uk
Subject: (none)
Date: Thu, 25 Jul 1996 20:19:46 +0100
Message-ID: <9607251520.aa14152 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
unsubscribe
Received: from ietf.org by ietf.org id aa15488; 25 Jul 96 16:53 EDT
Received: from cnri by ietf.org id aa15359; 25 Jul 96 16:51 EDT
Received: from ns.research.att.com by CNRI.Reston.VA.US id aa19553;
25 Jul 96 16:51 EDT
Received: from research.research.att.com by ns; Thu Jul 25 16:50:16 EDT 1996
Received: from smb.research.att.com.research.att.com by research; Thu Jul 25 16:49:01 EDT 1996
Received: from smb.research.att.com.research.att.com (smb at localhost) by smb.research.att.com.research.att.com (8.6.12/8.6.10) with ESMTP id NAA01665; Thu, 25 Jul 1996 13:49:06 -0700
Message-Id: <199607252049.NAA01665 at smb.research.att.com.research.att.com>
X-Authentication-Warning: smb.research.att.com.research.att.com: smb owned process doing -bs
To: Milton Clark <mclark at tribune.com>
cc: "'rory at carmelnet.com'" <rory at carmelnet.com>,
"ietf at CNRI.Reston.VA.US" <ietf at CNRI.Reston.VA.US>
Subject: Re: CIA snooping the net
Date: Thu, 25 Jul 1996 12:18:44 -0700
Sender:ietf-request at ietf.org
From: Steve Bellovin <smb at research.att.com>
Source-Info: From (or Sender) name not authenticated.
E-mail is not privileged material. However, it is currently under
review by the Supreme Court in re Wang. Anyone got anymore info?
Define ``privileged''. Mail in transit is protected by 18 USC 2510
(the wiretap statute); stored mail may, depending on context, be
protected by 18 USC 2700. The legal status of employee email on
company machines, against examination by the company, is unclear,
though the legislative history of the ECPA indicates that Congress
did not intend to protect such mail.
For the CIA's powers, see the Foreign Intelligence Surveillance Act
(50 USC 1800, I think). But I'll save you some trouble -- they're
not allowed to spy on net traffic.
Received: from ietf.org by ietf.org id aa16119; 25 Jul 96 17:28 EDT
Received: from cnri by ietf.org id aa16064; 25 Jul 96 17:26 EDT
Received: from weeble.lut.ac.uk by CNRI.Reston.VA.US id aa21722;
25 Jul 96 17:26 EDT
Received: from jon by weeble.lut.ac.uk with local (Exim 0.53 #1)
id E0ujXv6-0002OW-00; Thu, 25 Jul 1996 22:26:08 +0100
Date: Thu, 25 Jul 1996 22:26:08 +0100 (BST)
Sender:ietf-request at ietf.org
From: Jon Knight <jon at net.lut.ac.uk>
X-Sender: jon at weeble.lut.ac.uk
To: Steve Bellovin <smb at research.att.com>
cc: Milton Clark <mclark at tribune.com>,
"'rory at carmelnet.com'" <rory at carmelnet.com>,
"ietf at CNRI.Reston.VA.US" <ietf at CNRI.Reston.VA.US>
Subject: Re: CIA snooping the net
In-Reply-To: <199607252049.NAA01665 at smb.research.att.com.research.att.com>
Message-ID: <Pine.SUN.3.91.960725222257.3141N-100000 at weeble.lut.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orig-Sender: Jon Knight <J.P.Knight at lut.ac.uk>
Source-Info: From (or Sender) name not authenticated.
On Thu, 25 Jul 1996, Steve Bellovin wrote:
> For the CIA's powers, see the Foreign Intelligence Surveillance Act
> (50 USC 1800, I think). But I'll save you some trouble -- they're
> not allowed to spy on net traffic.
Nah, that's the NSA's job isn't it? :-) :-)
Tatty bye,
Jim'll
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer
Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU.
* I've found I now dream in Perl. More worryingly, I enjoy those dreams. *
Received: from ietf.org by ietf.org id aa27183; 26 Jul 96 2:47 EDT
Received: from corus.com by ietf.org id aa27040; 26 Jul 96 2:42 EDT
Received: (from tarak at localhost) by maverick.corus.com (8.6.11/8.6.9) id MAA18496 for ietf at ietf.org; Fri, 26 Jul 1996 12:13:43 +0530
Date: Fri, 26 Jul 1996 12:13:43 +0530
Sender:ietf-request at ietf.org
From: Tarak Parekh <tarak at corus.com>
Message-Id: <199607260643.MAA18496 at maverick.corus.com>
To: ietf at ietf.org
Subject: unsubscribe
Source-Info: From (or Sender) name not authenticated.
unsubscribe
Received: from ietf.org by ietf.org id aa29423; 26 Jul 96 5:41 EDT
Received: from cnri by ietf.org id aa29360; 26 Jul 96 5:39 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa05776;
26 Jul 96 5:39 EDT
Received: from internet-gw.zurich.ibm.com (internet-gw.zurich.ibm.ch) by venera.isi.edu (5.65c/5.61+local-25)
id <AA28350>; Fri, 26 Jul 1996 02:38:58 -0700
Received: from emme.zurich.ibm.com by internet-gw.zurich.ibm.com (AIX 3.2/UCB 5.64/4.03)
id AA13671 from <dga at zurich.ibm.com>; Fri, 26 Jul 1996 11:38:49 +0200
Received: from ahoreli.zurich.ibm.com by emme.zurich.ibm.com (AIX 3.2/UCB 5.64/4.03)
id AA65979 from <dga at zurich.ibm.com>; Fri, 26 Jul 1996 11:38:48 +0200
Return-Path: <dga at zurich.ibm.com>
Received: from salo.zurich.ibm.com by ahoreli.zurich.ibm.com (AIX 3.2/UCB 5.64/ZuriNotes0.9)
id AA14458; Fri, 26 Jul 1996 11:37:50 +0200
Received: by salo.zurich.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/2.12um) id AA8070; Fri, 26 Jul 96 11:34:55 +0200
Message-Id: <9607260934.AA8070 at salo.zurich.ibm.com>
Received: by Zurich (Lotus Notes Mail Gateway for SMTP V1.1) id
E483C483BBFCE9EDC125636F005FC1A9; Fri, 26 Jul 96 11:11:47
To: distribution: ;
Sender:ietf-request at ietf.org
From: Dieter Gantenbein/Zurich/IBM <dga at zurich.ibm.com>
Date: 22 Jul 96 19:28:47
Subject: -No Subject-
Mime-Version: 1.0
Content-Type: Text/Plain
Source-Info: From (or Sender) name not authenticated.
War at nt.com, comswtc at gmu.edu,
giga at tele.pitt.edu, enternet at bbn.com, ifip-nm at bbn.com,
cnom at maestro.bellcore.com, nmf-members at nmf.com, netmgt at ncri.com,
sig-dsm at doc.imperial.ac.uk, netmgt at ncri.com, enternet at bbn.com,
dsm at nemo.ncsl.nist.gov, nmsig at nemo.ncsl.nist.gov, aow-nmsig at stc.ipa.go.jp,
ewos-egnm at extend.iihe.ac.be, snmsigl at nemo.ncsl.nist.gov,
noms96 at joker.bellcore.com, corpcom at osf.org, nmf-members at nmf.org,
ifip-emailmgt at ics.uci.edu, snmp at psi.com, nadism at mbunix.mitre.org,
mitre-osi at bistromath.mitre.org, nsm-info at gateway.mitre.org,
x3t54 at mbunix.mitre.org, nmsig at ics.uci.edu, rwnmcc at external.iihe.rtt.be,
OSIMIS at cs.ucl.ac.uk, ietf-madman at innosoft.com, nms at netmgrs.co.uk,
iimc at thumper.bellcore.com, OVForum at andrew.cmu.edu,
ieeetcpc at ccvm.sunysb.edu, commsoft at cc.bellcore.com, comswtc at gmu.edu,
isinm97_oc at ctr.columbia.edu,
news.announce.conferences%USENET at maestro.bellcore.com,
ieee.announce at bellcore.com,
comp.protocols.snmp%USENET at maestro.bellcore.com,
comp.protocols.iso at bellcore.com, comp.org.ieee%USENET at maestro.bellcore.com,
barrere at irit.fr, benzekri at irit.fr, bergougn at irit.fr, betourne at irit.fr,
castanet at labri.u-bordeaux.fr, courtiat at laas.fr, cousin at irisa.fr,
diaz at laas.fr, fdida at masi.ibp.fr, filali at irit.fr, fourneau at masi.ibp.fr,
horlait at masi.ibp.fr, jard at irisa.fr, jezequel at irisa.fr, juanole at laas.fr,
mbl at lri.lri.fr, plateau at imag.imag.fr, Guy.Pujolle at prism.uvsq.fr,
rafiq at crisv2.univ-pau.fr, raynal at irisa.fr, raynaud at irit.fr,
trehel at comte.univ-fcomte.fr, hipparch at sophia.inria.fr,
lib at comte.univ-fcomte.fr, prs at uvsq.fr, prs at masi.ibp.fr,
tous.rumeur at lip.ens-lyon.fr, alg at comm.toronto.edu, BM-List1 at cs.ucdavis.edu,
cellular at dfv.rwth-aachen.edu, cnom at maestro.bellcore.com,
comsoc.bog at tab.ieee.org, comsoc-gicb at ieee.org, commsoft at cc.bellcore.com,
comswtc at gmu.edu, cost237-transport at comp.lancs.ac.uk,
ctc-members at redbank.tinac.com, enternet at bbn.com,
forte at informatik.uni-kl.de, gcomlist1 at manjaro.ece.iit.edu,
giga at tele.pitt.edu, ieeetcpc at ccvm.sunysb.edu, ieee_rtc_list at cs.tamu.edu,
isadsoc at fokus.gmd.de, modern-heuristics at uk.ac.mailbase.ucdavis.edu,
multicomm at cc.bellcore.com, osimcast at bbn.com, reres at comm.polymtl.ca,
reres at uklirb.informatik.uni-kl.de, sc6wg4 at ntd.comsat.com,
sigmedia at bellcore.com, tccc at cs.umass.edu, testnet at canarie.ca,
xtp-relay at cs.concordia.ca
From: a.galis (Alex Galis)
Subject: GLOBCOM'96 - London U.K. / 18-22 November 1996
Cc: a.galis at busby, c.todd at busby
Dear All,
In the name of the Organising Committee I am pleased to invite you to
attend GLOBCOM'96 Telecommunications Conference organised by IEEE in London
( 18th - 22nd November 1996).
Yours sincerely
Alex Galis
University College London
............................................................................
...........................
1996 IEEE GLOBAL TELECOMMUNICATIONS CONFERENCE
18th - 22nd November 1996
Queen Elizabeth II Conference Centre, Westminster, London
"Communications: The Key to Global Prosperity"
This major international communications conference, held annually for some
25 years, is to be hosted in London for its first staging in Europe.
Sponsored by the IEEE Communications Society and in conjunction with the
IEE, Globecom 96 aims to attract 1000+ of the leading telecommunication
development engineers, academics, operators and manufacturers from all parts
of the world.
The Conference will consist of 50 Technical Sessions (in 9 parallel tracks),
6 Sessions of a Mini-Conference on Communications Theory, 4 Sessions of a
Mini-Conference called "IEEE Global Internet '96" and 4 Panel Session
discussions on key Business Topics over the 3 days (Tuesday 19th, Wednesday
20th and Thursday 21st November 1996). On Monday 18th and Friday 22nd
November there will be some 27 half-day equivalent sessions devoted to
Tutorials and Workshops on key Hot Topics. Throughout the week there will
be a 20 stand Exhibition of sponsoring companies, publishers and future
ComSoc Conferences. In addition there will be a separate Exhibition on
Internet and related telecomms topics.
Hot Topics
The Hot Topics below have been identified by the ComSoc Technical
Committees. These titles have been accepted by the Globecom '96 Technical
Programme Committee as forming a basis on which to assemble Technical
Session and Tutorials etc.
- Advances in PCS
- Wireless ATM
- Advanced switching architectures for broadband networks
- Network issues in wireless communications
- Distributed Software Challenges
- Software Support for Interactive MultiMedia Services and Applications
- Wireless Communication and ATM
- Towards ATM Switching Systems with Terabit/s Capacity
- Signal Processing for Multimedia Services
- Advanced VLSI Signal Processing in Communications
- Quality of service for advanced communication services (PCS, Multimedia,
Internet)
- Software engineering technologies and experience to Improve and sustain
network quality objectives
- Mobile Satellite Communications
- Satellite Communications for Broadband Networks
- Security and Privacy in the GII/NII
- Multicasting
- Multimedia over the Internet
- Interactive Video Applications and Supporting Technologies
- Optical Access Networks and New Services Development
- Very High-Speed ( OC-192) Optical Transmission
Panel Sessions
These will consist of short presentations followed by discussion, lead by a
group of the leading Global Players on the Topics of:-
1. Visions of the 21st Century
2. Wireless revolution towards global roaming
3. The Information highway - market and service provider perspectives
4. Service and quality: customer's perceptions
Tutorials and Workshops - mixture of full and half day Sessions
The titles and leaders are:
Monday tutorials and workshop
T01 Telecommunications Management Network:- Standards, Implementation and
Applications (Veli Sahin, NEC America Inc)
T02 Introduction to ATM (Khosrow Sohraby, IBM)
T03 GSM - Recent Advances and Future Developments (Paul Kakaes, Cosmos
Communications Consulting)
T04 Traffic Modelling and Management in Wireless Communications Systems
(am) (Sirin Tekinay, Bell Northern Research)
T05 Modelling and Transmission issues for VBR video over B-ISDN Networks
(am) (Dr Ghanbari, University of Essex)
T06 High Speed Wireless Data (Len Cimini, AT&T Bell Laboratories and Andrea
Goldsmith, California Institute of Technology)
T07 JAVA (Prof John N Daigle)
T08 The Intelligent Network and Mobile System Control (pm) (Prof Bijan
Jabbari, George Mason University)
T09 Iterative Turbo-Decoding (pm) (Joachim Hagenauer, TU Munich)
T10 Interactive Multimedia over the Internet (pm) (Mark Handley and Ian
Wakemen, UCL and Sussex University)
W01 Very-high-speed Digital Subscriber Lines (Prof John M Cioffi, Stanford
University)
Friday tutorials and workshop
T11 Mobile and Multimedia Satellite Systems (Dr K M S Murthy, VISTAR
Telecommunications)
T12 Spread Spectrum Systems for PCS (Elvino S Sousa, University of Toronto)
T13 Mobility Management in TCP/IP Networks (Dr Zygmunt Haas, Cornell
University)
T14 Operation and Management of Multi-Wavelength Optical Networks (am) (Dr
Mari Maeda, Bell Communications Research)
T15 Internet IP Security (am) ( Ran Atkinson, Internet Security)
T16 Adaptive Antennas for Wireless Systems (pm) (Jack Winters, AT&T Bell
Laboratories)
T17 IP and ATM - Enterprise Internetworking (pm) (David Ginsburg, CISCO
Corp)
W02 Transport Protocols for High-Speed Broadband Networks (Douglas J Hoder,
NASA)
Although the Call-for-Paper deadline is March 1st 1996, further details of
the Globecom 96 Technical Programme are available from Professor Hamid
Aghvami, Tel: + 44 171 873 2898, Fax: + 44 171 836 4781, E-mail:
h.aghvami at kcl.ac.uk
CO1 Mini-Conference - Communications Theory
This will consist of 6 Sessions running as a separate stream in parallel
with the Main Sessions from Tuesday 19th to Thursday 21st November.
For further details contact General Chair, F Marvasti at
fam at orion.eee.kcl.ac.uk or for Call for Papers contact the Technical
Programme Chair, Enzin Bigliori at biglieri at polito.it
C02 Mini-Conference - IEEE Global Internet '96
This will consist of Technical Sessions, Panel Sessions, Tutorials, Keynote
Speeches and major player Demonstrations and Exhibits on the subject of the
Internet. The main sessions of the mini-conference are on Wednesday 20th
and Thursday 21st November. If successful, this may be the first of a new
annual IEEE ComSoc Conference on the topic.
For further details contact John Crowcroft at j.crowcroft at cs.ucl.ac.uk
London has of course, many tourist attractions and shopping facilities.
Opposite the Queen Elizabeth II Conference Centre (QEIICC) is Westminster
Abbey with the Houses of Parliament, Whitehall, Trafalgar Square, Buckingham
Palace and St. James s Park all within close walking distance. Globecom 96
have organised a range of tours and social functions. These are:-
SO1-Panoramic London Tour - Monday 18th (am) and Wednesday 20 November (pm)
SO2-St James's Walking Tour - Monday 18th (am)
SO3-Churchill War Rooms - two tours organised for Tuesday 19th November (am
or pm)
SO4-Westminster Abbey - two tours organised for Tuesday 19th November (am or
pm)
SO5-Thames Dinner Cruise - Tuesday 19th November (evening)
SO6-Windsor Castle and Runnymede - Wednesday 20th November (am)
SO7-Stratford-upon-Avon and Oxford - Thursday 21st November (all day)
Three post conference tours to Edinburgh(PO1), Paris(PO2) and Bath(PO3) have
also been organised commencing Friday 22nd to Sunday 24th November.
On Tuesday 19th November there will be an IEEE Awards Luncheon in the QEIICC
and on Wednesday evening (20th November) a Conference Banquet will be held
in the Banqueting Suite of Whitehall Palace which was built in 1620 for King
James 1st of England and Scotland.
Some 1000 bedrooms have been reserved in the area of the QEIICC, all within
10-20 minutes walk or 2-3 stops on the Underground - Circle Line - nearest
stations St. James's Park and Westminster. Prices range from ?30 - ?120 per
night per room.
Heathrow and Gatwick Airports, near London, between them serve more
International Destinations and Passengers than anywhere else. Special
discounted airfares are available from British Airways, when booking through
one of their offices and quoting reference CIC*115/30.
Within London, the network of Tube Trains, Buses and Taxis offer frequent
services to all local destinations.
Fuller, updated information is available via the Globecom '96 WWW homepage,
see:
http://www.labs.bt.com/profsoc/globecom/
If you would like a copy of the Early Registration form faxed to you, please
complete your details below and return via mail, fax or e-mail to Jane
Chopping (as below). Note that a version of the Registration form will
appear on the WWW pages above from mid June '96.
----------------------------------------------------------------------------
----------------------------------------
To: Jane Chopping
IEE Conference Tel: +44 171 344 5469
Savoy Place Fax: +44 171 497 3633
London E-mail: jchopping at iee.org.uk
WC2R 0BL, UK
----------------------------------------------------------------------------
----------------------------------------
FULL NAME AND TITLE:
JOB/POSITION:
COMPANY/UNIVERSITY:
ADDRESS:
CITY/STATE:
POSTCODE/ZIP CODE:
COUNTRY:
TELEPHONE NUMBER:
FAX NUMBER:
E-MAIL ADDRESS:
%%% overflow headers %%%
To: cnom <cnom at maestro.bellcore.com>, nhe <nhe at postman.dg13.cec.be>,
"announcements.chi"
<announcements.chi at xerox.com>,
arl <arl at arl1.wustl.edu>,
arpanet-bboard
<arpanet-bboard at mc.lcs.mit.edu>, atm <atm at bbn.com>,
bcs-hci-request
<bcs-hci-request at mailbase.ac.uk>,
ccrc <ccrc at dworkin.wustl.edu>, cellular
<cellular at dfv.rwth-aachen.de>,
cip <cip at bbn.com>, cnom <cnom at maestro.bellcore.com>,
cybsys-l <cybsys-l at bingvmb.cc.binghamton.edu>,
diagrams
<diagrams at cs.swarthmore.edu>,
elsnet-list <elsnet-list at cogsci.ed.ac.uk>,
end2end-interest <end2end-interest at isi.edu>,
enternet-ec <enternet-ec at bbn.com>, enternet <enternet at bbn.com>,
f-troup <f-troup at aurora.cis.upenn.edu>,
g-troup <g-troup at dworkin.wustl.edu>,
globecom
<globecom at signet.com.sg>,
hipparch <hipparch at sophia.inria.fr>,
icad-request
<icad-request at santafe.edu>,
ie-list <ie-list at cs.ucl.ac.uk>, ietf <ietf at isi.edu>,
ikbsbb <ikbsbb at inf.rl.ac.uk>, iplpdn <iplpdn at cnri.reston.va.us>,
kdd <kdd at gte.com>, perform <perform at tay1.dec.com>,
rem-conf <rem-conf at es.net>, sig11 <sig11 at roses.stanford.edu>,
sigmedia <sigmedia at bellcore.com>, smds <smds at cnri.reston.va.us>,
sound <sound at acm.org>,
tf-mm
<tf-mm at i4serv.informatik.rwth-aachen.de>,
"uist.chi" <uist.chi at xerox.com>, visual-l <visual-l at vtvm1.cc.vt.edu>,
xtp-relay <xtp-relay at cs.concordia.ca>,
commsoft <commsoft at cc.bellcore.com>, cnom <cnom at maestro.bellcore.com>,
utheorynt
<utheorynt at vm1.nodak.edu>,
ietf-announce <ietf-announce at cnri.reston.va.us>,
sigmedia <sigmedia at bellcore.com>, ccrc <ccrc at dworkin.wustl.edu>,
ie-list
<ie-list at cs.ucl.ac.uk>,
cost237-transport <cost237-transport at comp.lancs.ac.uk>,
arpanet-bboard <arpanet-bboard at mc.lcs.mit.edu>, atm
<atm at bbn.com>,
batnir <batnir at agcs.com>, "klaus.baumer" <klaus.baumer at telekom.dbp.de>,
besier <besier at eurescom.d400.de>, vab <vab at cc.bellcore.com>,
"/dd.fax=14079558015/G=Stephen/S=Cannon/ADMD=MCI/C=US
/" </dd.fax=14079558015/G=Stephen/S=Cannon/ADMD=MCI/C=US/@qmx400gate.nt.com>,
"laura.cerchio" <laura.cerchio at cselt.stet.it>,
"j.cheong"
<j.cheong at trl.oz.au>, TAIR <TAIR at zurich.ibm.com>,
cnom <cnom at maestro.bellcore.com>,
"Edwin.Frank.Crabill" <Edwin.Frank.Crabill at att.att.com>,
DCrosby <DCrosby at VTRLMEL1.TRL.OZ.AU>,
"/dd.id=ME.Cullum
/ADMD=TELECOM.CANADA/C=CA/" </dd.id=ME.Cullum/ADMD=TELECOM.CANADA/C=CA/@qmx400gate.nt.com>,
"dick.dodd" <dick.dodd at bridge.bst.bls.com>,
adoughe
<adoughe at Gateway.Uswnvg.COM>, enternet <enternet at bbn.com>,
javan <javan at comm.toronto.edu>,
"fulvio.faraci" <fulvio.faraci at MacPost.cselt.stet.it>,
igorf <igorf at arch4.att.com>, rlfike <rlfike at aol.com>,
fogarty <fogarty at eurescom.d400.de>, larryg <larryg at arch4.att.com>,
edgar <edgar at tid.es>, geradsd <geradsd at agcs.com>,
bur_goode <bur_goode at vnet.ibm.com>, gotz
<gotz at cc.bellcore.com>,
"epa.epacdh" <epa.epacdh at memo3.ericsson.se>,
bich
<bich at cc.bellcore.com>,
"epa.epajkj" <epa.epajkj at memo3.ericsson.se>,
"roberto.kung"
<roberto.kung at issy.cnet.fr>,
kusaura <kusaura at krsun.nslab.ntt.jp>, hlu
<hlu at arch4.att.com>,
kjl <kjl at cc.bellcore.com>, ilka <ilka at prz.tu-berlin.de>,
mukasa <mukasa at ast.lab.kdd.co.jp>, niitsu <niitsu at krsun.nslab.ntt.jp>,
oyamada <oyamada at krsun.nslab.ntt.jp>,
"etienne.paul"
<etienne.paul at issy.cnet.fr>,
ieeetcpc <ieeetcpc at ccvm.sunysb.edu>, swami
<swami at cc.bellcore.com>,
commsoft <commsoft at cc.bellcore.com>,
"roberto.saracco"
<roberto.saracco at cselt.stet.it>,
seb <seb at cc.bellcore.com>, cjs1 <cjs1 at psp.att.com>,
hikaru <hikaru at kopenews.nslab.ntt.jp>,
0002912712
<0002912712 at mcimail.com>,
"/dd.id=towaij.s/ADMD=TELECOM.CANADA/C=CA/" </dd.id=towaij.s/ADMD=TELECOM.CANADA/C=CA/@qmx400gate.nt.com>
%%% end overflow headers %%%
Received: from ietf.org by ietf.org id aa00881; 26 Jul 96 7:22 EDT
Received: from cnri by ietf.org id aa00820; 26 Jul 96 7:20 EDT
Received: from [204.189.94.36] by CNRI.Reston.VA.US id aa08727;
26 Jul 96 7:20 EDT
Received: by pilotx.firewall.is.chrysler.com; id HAA12471; Fri, 26 Jul 1996 07:19:51 -0400
Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilotx.is.chrysler.com via smap (g3.0.1)
id sma012465; Fri, 26 Jul 96 07:19:32 -0400
Received: from rgm3 by mhbclpr2-nf0.is.chrysler.com (8.7.5/SMI-4.1)
id HAA08575; Fri, 26 Jul 1996 07:12:53 -0400 (EDT)
Message-Id: <2.2.32.19960726111837.00c7286c at pop3hub.is.chrysler.com>
X-Sender: t3125rm at pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 26 Jul 1996 07:18:37 -0400
To: Steve Bellovin <smb at research.att.com>, Milton Clark <mclark at tribune.com>
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: CIA snooping the net
Cc: "'rory at carmelnet.com'" <rory at carmelnet.com>,
"ietf at CNRI.Reston.VA.US" <ietf at CNRI.Reston.VA.US>
Source-Info: From (or Sender) name not authenticated.
At 12:18 PM 7/25/96 -0700, Steve Bellovin wrote:
> E-mail is not privileged material. However, it is currently under
> review by the Supreme Court in re Wang. Anyone got anymore info?
>
>Define ``privileged''. Mail in transit is protected by 18 USC 2510
>(the wiretap statute); stored mail may, depending on context, be
>protected by 18 USC 2700. The legal status of employee email on
>company machines, against examination by the company, is unclear,
>though the legislative history of the ECPA indicates that Congress
>did not intend to protect such mail.
ECPA is worded such that a company can state in their policies that there is
no privacy in corporate email and have it stick. I helped draft such
wording here....
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.org by ietf.org id aa02014; 26 Jul 96 8:29 EDT
Received: from cnri by ietf.org id aa01952; 26 Jul 96 8:26 EDT
Received: from mail.iez.com by CNRI.Reston.VA.US id aa10007; 26 Jul 96 8:26 EDT
Received: by iez.com (AIX 3.2/UCB 5.64/4.03)
id AA11631; Fri, 26 Jul 1996 14:28:01 +0200
Received: from spibm02(172.16.13.62) by iez.com via smap (V1.3)
id sma008045; Fri Jul 26 14:27:46 1996
Received: from iez.com by spibm02 (AIX 3.2/UCB 5.64/4.03)
id AA12391; Fri, 26 Jul 1996 14:26:50 +0200
Message-Id: <9607261226.AA12391 at spibm02>
Received: from inhps-a by iez.com with SMTP
(1.37.109.4/16.2) id AA11126; Fri, 26 Jul 96 14:26:48 +0200
Received: by inhps-a
(1.38.193.3/16.2) id AA03284; Fri, 26 Jul 96 14:26:46 +0200
Sender:ietf-request at ietf.org
From: Rolf Weber <weber at iez.com>
Subject: Re: CIA snooping the net
To: Robert Moskowitz <rgm3 at chrysler.com>
Date: Fri, 26 Jul 1996 14:26:46 +0200 (MESZ)
Cc: smb at research.att.com, mclark at tribune.com, rory at carmelnet.com,
ietf at CNRI.Reston.VA.US
In-Reply-To: <2.2.32.19960726111837.00c7286c at pop3hub.is.chrysler.com> from "Robert Moskowitz" at Jul 26, 96 07:18:37 am
Content-Transfer-Encoding: quoted-printable
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1255
Source-Info: From (or Sender) name not authenticated.
>
> At 12:18 PM 7/25/96 -0700, Steve Bellovin wrote:
> > E-mail is not privileged material. However, it is currently under
> > review by the Supreme Court in re Wang. Anyone got anymore info?
> >
> >Define ``privileged''. Mail in transit is protected by 18 USC 2510
> >(the wiretap statute); stored mail may, depending on context, be
> >protected by 18 USC 2700. The legal status of employee email on
> >company machines, against examination by the company, is unclear,
> >though the legislative history of the ECPA indicates that Congress
> >did not intend to protect such mail.
>
> ECPA is worded such that a company can state in their policies that there is
> no privacy in corporate email and have it stick. I helped draft such
> wording here....
>
if you're interested in german situation:
privacy is protected by basic law, but email was never put into
criminal law (unlike phone or letter correspondance).
recently, a prosecuting attorney required AOL to censor emails.
otherwise, they would be responsible for illegal contence. no joke.
rolf
--
-----------------------------------------
Rolf Weber <weber at iez.com> | All I ask is a chance
IEZ AG D-64625 Bensheim | to prove that money
++49-6251-1309-109 | can't make me happy.
Received: from ietf.org by ietf.org id aa04629; 29 Jul 96 11:11 EDT
Received: from cnri by ietf.org id aa04625; 29 Jul 96 11:11 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa05774; 29 Jul 96 11:11 EDT
Received: from ietf.org by ietf.org id aa04616; 29 Jul 96 11:11 EDT
Received: from cnri by ietf.org id aa04603; 29 Jul 96 11:11 EDT
Received: from callc2.competitive.com by CNRI.Reston.VA.US id aa05768;
29 Jul 96 11:11 EDT
Received: by callc2.competitive.com with Microsoft Exchange (IMC 4.0.838.14)
id <01BB7D3E.5E475C80 at callc2.competitive.com>; Mon, 29 Jul 1996 11:09:10 -0400
Message-ID: <c=US%a=_%p=Competitive_Comp%l=CALLC2-960729150850Z-315 at callc2.competitive.com>
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: JohnM <JohnM at competitive.com>
To: "'davidc at APNIC.NET'" <davidc at apnic.net>, "'dfk at RIPE.NET'" <dfk at ripe.net>,
"'kimh at internic.net'" <kimh at internic.net>,
"'markk at internic.net'" <markk at internic.net>,
"'Postel at ISI.EDU'" <Postel at isi.edu>, 'Jim Browning' <jfbb at atmnet.net>
Cc: 'CIDRD List' <cidrd at iepg.org>, 'IESG' <iesg at CNRI.Reston.VA.US>,
'IETF' <ietf at CNRI.Reston.VA.US>
Subject: RE: draft-hubbard-registry-guidelines-03.txt
Date: Mon, 29 Jul 1996 11:08:50 -0400
Return-Receipt-To: <JohnM at Competitive.Com>
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
It seems as if there is quite a bit of political wrangling over IP
addresses and how they should be doled out and administered.
Consider the Internet-draft that would allow all IP addresses to be
created and used dynamically. Addresses would be created primarily by
using global positioning (latitude-longitude-altitude) information
coupled with MAC addresses (network interface card manufacturer/serial
numbers).
The draft is in the IETF internet draft area and is entitled
"draft-mangione-ipv6-gps-alt-00.txt"
Wouldn't it make IP address management simpler?
>----------
>From:Jim Browning[SMTP:jfbb at atmnet.net]
>Sent:Saturday, July 20, 1996 8:42 PM
>To:'davidc at APNIC.NET'; 'dfk at RIPE.NET'; 'kimh at internic.net';
>'markk at internic.net'; 'Postel at ISI.EDU'
>Cc:'CIDRD List'; 'IESG'; 'IETF'
>Subject:draft-hubbard-registry-guidelines-03.txt
>
>As reflected in the minutes of the CIDRD WG meeting in Montreal, the
>IESG
>has requested additional comments on the referenced draft. To the
>extent
>that this message reiterates comments I made about the earlier draft, I
>
>apologize for the redundancies, however if they are included here, it
>is
>because my earlier comments still apply:
>
>
>> 1. Introduction
>>
>>
>> Internet address space is distributed according to the following
>> three goals:
>>
>> 1) Conservation: Fair distribution of globally unique Internet address
>> space according to the operational needs of the end-users and Internet
>> Service Providers operating networks using this address space.
>> Prevention of stockpiling in order to maximize the lifetime of the
>> Internet address space.
>
>The reference to "Fair distribution" should be removed from the
>Conservation paragraph because it is out of context. Fair Distribution
>and
>Conservation are both important goals, but they are not the *same*
>goals.
> In fact, the two often conflict. I recommend that they be split into
>separate goals by adding the following:
>
> 4) Fair Distribution: Allocation of IP addresses according to the
>operational needs of end-users, fairly and objectively determined.
>
>> It is in the interest of the Internet community as a whole that the
>> above goals be pursued. However it should be noted that
>> "Conservation" and "Routability" are often conflicting goals. All
>> the above goals may sometimes be in conflict with the interests of
>> individual end-users or Internet service providers. Careful analysis
>> and judgement is necessary in each individual case to find an
>> appropriate compromise.
>
>Compromise is not an appropriate goal. It presumes that there will be
>a
>negotiation, and that the end result will be the allocation of an
>address
>block smaller than requested, but larger than initially offered. As
>opposed to 'judgment and compromise'', the goal should be "the
>consistent
>application of objective criteria", which will result in a correct and
>supportable decision. Compromises, while they give something to each
>party
>in a negotiation, rarely result in the best decision.
>
>> IANA
>>
>> The Internet Assigned Numbers Authority has authority over all number
>> spaces used in the Internet. This includes Internet Address Space. IANA
>> allocates parts of the Internet address space to regional IRs according
>> to its established needs.
>
>The source of IANA's authority should be referenced:
><draft-ietf-poised95-ietf-orgs-03.txt>, or another more definitive
>reference if there is one.
>
>
>> Regional IRs
>>
>> Regional IRs are established under the authority of the IANA. This
>> requires consensus within the Internet community of the region. A con-
>> sensus of Internet Service Providers in that region may be necessary to
>> fulfill that role.
>
>The process for establishing these IRs should be clearly defined, as
>should
>the mechanisms for evaluating whether the distribution goals outlined
>in
>this draft are being met.
>
>> The specific duties of the regional IRs include coordination and
>> representation of all local IRs in its respective regions.
>
>The duties of the IRs should include meeting the distribution
>objectives
>and ensuring that local IRs meet them as well.
>
>
>> Local IRs
>>
>> Local IRs are established under the authority of the regional IR and
>> IANA. These local registries have the same role and responsibility as
>> the regional registries within its designated geographical areas. These
>> areas are usually of national dimensions.
>
>Just as with the IRs, The process for establishing Local IRs should be
>clearly defined, as should the mechanisms for evaluating whether the
>distribution goals outlined in this draft are being met at the local
>level.
>
>>
>> 2. Allocation Framework
>>
>> 2.1 Guidelines for Internet Service Providers (ISPs)
>[snip]
>> ISPs who exchange routing information with other ISPs at multiple loca-
>> tions and operate without default routing may request space directly
>> from the regional registry in its geographical area.
>
>Many multi-homed ISPs, with peering agreements in place, choose to
>maintain
>a default route as well. I see no reason why this draft should
>prohibit
>such an ISP from obtaining a direct allocation of addresses when other
>factors indicate that it is appropriate.
>
>[snip]
>> To facilitate hierarchical addressing, implemented using Classless
>> Inter-Domain Routing (CIDR), all other ISPs should request address space
>> directly from its upstream provider. ISPs only request address space
>> directly from regional registries if their immediate requirement, when
>> satisfied with a contiguous block allocation, has a reasonable probabil-
>> ity of being routable on the Internet, and they meet one or more of the
>> following conditions.
>>
>> a) the ISP is directly connected to a major routing exchange
>> (for purposes of this document, a major routing exchange
>> is defined as a neutral layer 2 exchange point connecting
>> four or more unrelated ISPs.)
>
>The issue of physical connectivity should not be a concern of this
>draft.
> Many people believe that the future will see an increased reliance on
>regional exchanges (which may or may not fit the above definition) and
>private exchange/peering agreements which do not occur at an exchange
>point. Several major NSPs have begun taking the private exchange
>(between
>only two providers) approach in order to reduce congestion at the NAPs.
>
> There is no reason these efforts should be discouraged through IP
>allocation policy. The issue is whether there is a valid need for
>addresses, and this has little to do with where networks are exchanging
>
>traffic.
>
>> b) the ISP is multi-homed, that is, it has more than one
>> simultaneous connection to the global Internet and no
>> connection is favored over the other
>
>I don't understand why favoring one connection over another should be a
>
>factor. I also fail to see how this can be objectively determined.
>Does
>this mean that if an ISP is multi-homed with two connections of the
>same
>speed to two different NSPs, but she pads her AS path for one of them
>so
>route traffic is carried on a preferred (for whatever reason) path,
>that
>she can not obtain a direct allocation of addresses? I think this
>approach
>prevents the application of objective criteria.
>
>> The following are the IP allocation guidelines for ISPs:
>[snip]
>> 4. IP addresses are allocated to ISPs using a slow-start
>> procedure. New ISPs will receive a minimal amount based
>> on immediate requirement. Thereafter, allocated blocks may be
>> increased based on utilization verification supplied to the
>> regional registry. The parent registries are responsible for
>> determining appropriate initial and subsequent allocations.
>> Additional address allocations will provide enough address space
>> to enable the ISP to assign addresses for three months
>> without requesting additional address space from its parent
>> registry. Please note that projected customer base has little
>> impact on the address allocations made by the parent registries.
>> Initial allocation will not be based on any current or future
>> routing restrictions but on demonstrated requirements.
>
>There is an apparent conflict between this paragraph and later (Section
>3)
>paragraphs which reference a one-year period which will be taken into
>account, and that there needs to be only 50% utilization in the first
>year.
>
>[snip]
>> 6. Regional registries may set a maximum limit on assignment sizes
>> such that a second opinion of the regional registry is required.
>
>This appears to be discussing the internal mechanics of a registry, but
>
>only with respect to one detail. If the draft is going to define *how*
>a
>registry meets the distribution goals, then there are a whole host of
>other
>details that need to be specified. I suggest either deleting this
>paragraph, or restating it so that it addresses obtaining additional
>opinions from regional registries parent registry.
>
>[snip]
>> 3. Assignment Framework
>>
>> An assignment is the delegation of authority over a block of IP
>> addresses to an end enterprise. The end enterprise will use addresses
>> from an assignment internally only; it will not sub-delegate those
>> addresses. This section discusses some of the issues involved in
>> assignments and the framework behind the assignment of addresses.
>>
>> In order for the Internet to scale using existing technologies, use of
>> regional registry services should be limited to the assignment of IP
>> addresses for organizations meeting one or more of the following condi-
>> tions:
>>
>> a) the organization has no intention of connecting to
>> the Internet-either now or in the future-but it still
>> requires a globally unique IP address. The organization
>> should consider using reserved addresses from RFC1918.
>> If it is determined this is not possible, they can be
>> issued unique (if not Internet routable) IP addresses.
>>
>> b) the organization is multi-homed with no favored connection.
>>
>> c) the organization's actual requirement for IP space is
>> very large, for example, the network prefix required to
>> cover the request is of length /18 or shorter.
>
>If I am reading section 3 correctly (the wording could be clearer), it
>is
>differentiating between end users who want to obtain addresses from a
>registry, and ISPs who want to obtain addresses from a registry. Why
>the
>distinction? Why should an end user with a large (/18 or shorter)
>requirement be allowed to obtain addresses from a registry, when an ISP
>
>with a similar size requirement must also meet other criteria (NAP
>connection, multi-homing, etc.). If there are to be different criteria
>
>based upon whether a requester will be assigning addresses to other
>entities, I would think the criteria should be less confining for the
>ISP,
>as the size of her address space is more likely to increase in the
>future,
>and she is more likely to end up with a NAP connection and/or be
>multi-homed.
>
>This revision is much improved, although I believe there are
>substantive
>issues (e.g., how registries are established) which must still be
>addresses
><NPI>. I appreciate the effort put forth by its authors, and the
>opportunity to provide additional comments.
>--
>Jim Browning <jfbb at ATMnet.net>
>619/643-1802 Fax 619/643-1801
>
>
>
Received: from ietf.org by ietf.org id aa06591; 29 Jul 96 14:33 EDT
Received: from cnri by ietf.org id aa06587; 29 Jul 96 14:33 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa20111; 29 Jul 96 14:33 EDT
Received: from ietf.org by ietf.org id aa06578; 29 Jul 96 14:33 EDT
Received: from cnri by ietf.org id aa06555; 29 Jul 96 14:33 EDT
Received: from smtp1.erols.com by CNRI.Reston.VA.US id aa20102;
29 Jul 96 14:33 EDT
Received: from justin.erols.com (justin.erols.com [205.252.116.48]) by smtp1.erols.com (8.7.4/8.6.5) with SMTP id OAA00187; Mon, 29 Jul 1996 14:32:51 -0400 (EDT)
Message-Id: <2.2.32.19960729184017.0072164c at pop.erols.com>
X-Sender: justin at pop.erols.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 29 Jul 1996 14:40:17 -0400
To: JohnM <JohnM at competitive.com>, "'davidc at APNIC.NET'" <davidc at apnic.net>,
"'dfk at RIPE.NET'" <dfk at ripe.net>,
"'kimh at internic.net'" <kimh at internic.net>,
"'markk at internic.net'" <markk at internic.net>,
"'Postel at ISI.EDU'" <Postel at isi.edu>, 'Jim Browning' <jfbb at atmnet.net>
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: "Justin W. Newton" <justin at erols.com>
Subject: RE: draft-hubbard-registry-guidelines-03.txt
Cc: 'CIDRD List' <cidrd at iepg.org>, 'IESG' <iesg at CNRI.Reston.VA.US>,
'IETF' <ietf at CNRI.Reston.VA.US>
At 11:08 AM 7/29/96 -0400, JohnM wrote:
>It seems as if there is quite a bit of political wrangling over IP
>addresses and how they should be doled out and administered.
>
>Consider the Internet-draft that would allow all IP addresses to be
>created and used dynamically. Addresses would be created primarily by
>using global positioning (latitude-longitude-altitude) information
>coupled with MAC addresses (network interface card manufacturer/serial
>numbers).
>
>The draft is in the IETF internet draft area and is entitled
>
>"draft-mangione-ipv6-gps-alt-00.txt"
>
>Wouldn't it make IP address management simpler?
Uhm, do the words "Unmanageable routing tables" mean anything to you?
Hey, you build a router that can support it for ~$30k a pop and the world
will beat a path too your door.
Justin Newton
Internet Architect
Erol's Internet Services
Received: from ietf.org by ietf.org id aa06608; 29 Jul 96 14:34 EDT
Received: from cnri by ietf.org id aa06604; 29 Jul 96 14:34 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20136;
29 Jul 96 14:34 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <RAA10260 at pad-thai.cam.ov.com>; Mon, 29 Jul 1996 17:54:08 GMT
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA25431; Mon, 29 Jul 96 13:54:01 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <RAA10256 at pad-thai.cam.ov.com>; Mon, 29 Jul 1996 17:53:59 GMT
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id NAA16795; Mon, 29 Jul 1996 13:53:52 -0400
Message-Id: <199607291753.NAA16795 at winkl.cam.ov.com>
To: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Cc: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Regarding sneg-mech
In-Reply-To: Your message of "Fri, 19 Jul 1996 16:38:41 BST."
<9607191538.AA28513 at emsc.frcl.bull.fr>
Date: Mon, 29 Jul 1996 13:53:51 -0400
Sender:ietf-archive-request at ietf.org
From: John Linn <linn at cam.ov.com>
CAT/sneg fanciers:
A number of messages were exchanged earlier this month about the
Simple Negotiation Internet-Draft (draft-ietf-cat-snego-01.txt),
following the renewed solicitation for review and comment issued at
the Montreal IETF. The purpose of this message is to review the state
of discusssion.
On 15 July, Dennis Glatting raised two issues, which I'll briefly
summarize as follows:
(1) whether the approach embodied in the snego draft, of defining
options within mechanisms as suffixes to the mechanism's OID, was
unduly restrictive to independent organizations wishing to extend
a defined mechanism
(2) whether the approach embodied in the snego draft, in which no
cryptographic protection is applied to the negotiation tokens, was
acceptable from a security perspective.
Given these concerns, Dennis suggested that the current draft be
submitted for Experimental status. Discussion followed on both points,
though more extensively on (2) than (1).
Re (1), no changes to the draft were suggested, and no alternate
approaches for option representation were proposed. The desire for a
neutral means for registration of options within a mechanism did,
however, illuminate rationale for using IANA-arc OIDs to register
mechanisms for IETF standards purposes.
Re (2), several participants noted that, given the fact that
negotiation of a particular mechanism/option combination will succeed
only if that combination is declared acceptable to both peers, it did
not appear necessary to defend against the man-in-the-middle attack.
Considering another aspect of (2), the purpose of the negotiation
mechanism itself is to identify a common mechanism; under current
assumptions, no shared protection mechanism can be assumed available
when negotiation is initiated. More than one participant noted,
however, concern that an attacker could force reordering among the
mechanism/option lists presented, presumably to skew the result
towards weaker alternatives and/or to influence the set of services
which could be available to a requester at a target which grants
different privileges depending on the active mechanism. These
discussions led to Bill Sommerfeld's suggestion that the following
steps should be incorporated:
>The `snego' exchange should (logically) be, in sequence:
>
>- cleartext negotiation to find common mechanism
>- crypto negotiation to establish mechanism
>- exchange of MAC of negotiation parameters
>
>During the third stage, the peers can each verify that the other
>received the "offer" which they sent; if they didn't, the negotiation
>can be terminated.
>
>Now, this is this is logically three round trips, which is a bit excessive.
>
>We should borrow a trick from SSH and ISAKMP to save a round trip or two:
>
> - We should allow the initiator to "guess" which mechanism will be
>accepted, and piggyback the initial token for that mechanism with the
>parameters. [...]
>
> - if the mechanism allows is (e.g., kerberos will allow it), you can
>piggyback the MAC of the parameters along with the initial token.
Denis responded, excerpting:
>If we could have a standard way to piggy back the negotiation token and
>the first init token, I would say that this would be valuable.
Questions: is it feasible to treat this case in the draft? Can this
form of protected negotiation be accomplished in a
mechanism-independent fashion by expressing its definition in terms of
where/how the chosen common mechanism's gss_seal() and/or gss_sign()
are applied?
>
>At this time, I have not think about the implications but my
>feeling is that we would be loosing some functionality: today the code
>cannot distinguish whether it is doing a negotiation or a multiple
>authentication exchange without negotiation ... and this is fine.
Question: which layer of code is being considered in the second line?
Assuming that we're considering the level of a GSS-API caller, why
wouldn't a protected exchange (with or without piggybacking) fit under
the continue-needed facility as well as the sequence of a
currently-defined snego exchange followed by tokens for the selected
mechanism?
--jl
Received: from ietf.org by ietf.org id aa07216; 29 Jul 96 15:01 EDT
Received: from cnri by ietf.org id aa07212; 29 Jul 96 15:01 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa20516; 29 Jul 96 15:01 EDT
Received: from ietf.org by ietf.org id aa07204; 29 Jul 96 15:01 EDT
Received: from cnri by ietf.org id aa07191; 29 Jul 96 15:01 EDT
Received: from lint.cisco.com by CNRI.Reston.VA.US id aa20511;
29 Jul 96 15:01 EDT
Received: from pferguso-pc.cisco.com (c4robo12.cisco.com [171.68.13.108]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id MAA12956; Mon, 29 Jul 1996 12:00:25 -0700
Message-Id: <199607291900.MAA12956 at lint.cisco.com>
X-Sender: pferguso at lint.cisco.com
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 29 Jul 1996 14:59:21 -0400
To: JohnM <JohnM at competitive.com>
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Paul Ferguson <pferguso at cisco.com>
Subject: RE: draft-hubbard-registry-guidelines-03.txt
Cc: "'davidc at APNIC.NET'" <davidc at apnic.net>, "'dfk at RIPE.NET'" <dfk at ripe.net>,
"'kimh at internic.net'" <kimh at internic.net>,
"'markk at internic.net'" <markk at internic.net>,
"'Postel at ISI.EDU'" <Postel at isi.edu>, 'Jim Browning' <jfbb at atmnet.net>,
'CIDRD List' <cidrd at iepg.org>, 'IESG' <iesg at CNRI.Reston.VA.US>,
'IETF' <ietf at CNRI.Reston.VA.US>
At 11:08 AM 7/29/96 -0400, JohnM wrote:
>
>Consider the Internet-draft that would allow all IP addresses to be
>created and used dynamically. Addresses would be created primarily by
>using global positioning (latitude-longitude-altitude) information
>coupled with MAC addresses (network interface card manufacturer/serial
>numbers).
>
Out of morbid curiousity, what happens to the plethora of devices which
are backhauled?
(For what its worth, I like Kim Hubbard's [et al.] draft.)
- paul
Received: from ietf.org by ietf.org id aa07599; 29 Jul 96 15:10 EDT
Received: from cnri by ietf.org id aa07595; 29 Jul 96 15:10 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa20622; 29 Jul 96 15:10 EDT
Received: from ietf.org by ietf.org id aa07577; 29 Jul 96 15:09 EDT
Received: from cnri by ietf.org id aa07562; 29 Jul 96 15:09 EDT
Received: from glaucus.cso.uiuc.edu by CNRI.Reston.VA.US id aa20612;
29 Jul 96 15:09 EDT
Received: from resnick1.isdn.uiuc.edu by glaucus.cso.uiuc.edu (AIX 3.2/UCB 5.64/4.03)
id AA11917; Mon, 29 Jul 1996 14:04:48 -0500
X-Sender: resnick at glaucus.cso.uiuc.edu
Message-Id: <v03007801ae22bc1b6de1 at resnick1.isdn.uiuc.edu>
In-Reply-To:
<c=US%a=_%p=Competitive_Comp%l=CALLC2-960729150850Z-315 at callc2.competitive
.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Eudora [Macintosh version 3.0]
Date: Mon, 29 Jul 1996 14:08:03 -0500
To: JohnM <JohnM at competitive.com>
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Pete Resnick <presnick at qualcomm.com>
Subject: RE: draft-hubbard-registry-guidelines-03.txt
Cc: "'davidc at APNIC.NET'" <davidc at apnic.net>, "'dfk at RIPE.NET'" <dfk at ripe.net>,
"'kimh at internic.net'" <kimh at internic.net>,
"'markk at internic.net'" <markk at internic.net>,
"'Postel at ISI.EDU'" <Postel at isi.edu>, 'Jim Browning' <jfbb at atmnet.net>,
'CIDRD List' <cidrd at iepg.org>, 'IESG' <iesg at CNRI.Reston.VA.US>,
'IETF' <ietf at CNRI.Reston.VA.US>
On 7/29/96 at 10:08 AM -0500, JohnM wrote:
>Consider the Internet-draft that would allow all IP addresses to be
>created and used dynamically. Addresses would be created primarily by
>using global positioning (latitude-longitude-altitude) information
>coupled with MAC addresses (network interface card manufacturer/serial
>numbers).
Well, I am quite sure that the people in my company who sell these GPS
beasties would be pleased to see it to everyone who needs an IP address
this way! :-)
Does this mean that if I am in an airplane, my IP address would change
REALLY REALLY FAST?
pr
--
Pete Resnick <mailto:presnick at qualcomm.com>
QUALCOMM Incorporated
Work: (217)337-6377 / Fax: (217)337-1980
Received: from ietf.org by ietf.org id aa27623; 30 Jul 96 2:53 EDT
Received: from cnri by ietf.org id aa27619; 30 Jul 96 2:53 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa02563; 30 Jul 96 2:53 EDT
Received: from ietf.org by ietf.org id aa27612; 30 Jul 96 2:53 EDT
Received: from cnri by ietf.org id aa27598; 30 Jul 96 2:53 EDT
Received: from noc.BelWue.DE by CNRI.Reston.VA.US id aa02553; 30 Jul 96 2:53 EDT
Received: from rubin.noc.dfn.de (rubin.noc.dfn.de [193.174.247.201]) by noc.belwue.de with SMTP id IAA12791
(8.6.13/IDA-1.6); Tue, 30 Jul 1996 08:49:51 +0200
Received: from diamant.noc.dfn.de by rubin.noc.dfn.de (4.1/BelWue-2.0SUN)
id AA27387; Tue, 30 Jul 96 08:49:50 +0200
Received: by diamant.noc.dfn.de (SMI-8.6/SVR4/BelWue-1.0.3)
id IAA18460; Tue, 30 Jul 1996 08:47:22 +0200
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Jens Schweikhardt <Schweikhardt at rus.uni-stuttgart.de>
Message-Id: <199607300647.IAA18460 at diamant.noc.dfn.de>
Subject: Re: draft-hubbard-registry-guidelines-03.txt
To: Pete Resnick <presnick at qualcomm.com>
Date: Tue, 30 Jul 1996 08:47:22 +0200 (MET DST)
Cc: JohnM at competitive.com, davidc at apnic.net, dfk at ripe.net, kimh at internic.net,
markk at internic.net, Postel at isi.edu, jfbb at atmnet.net, cidrd at iepg.org,
iesg at CNRI.Reston.VA.US, ietf at CNRI.Reston.VA.US
In-Reply-To: <v03007801ae22bc1b6de1 at resnick1.isdn.uiuc.edu> from "Pete Resnick" at Jul 29, 96 02:08:03 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
> On 7/29/96 at 10:08 AM -0500, JohnM wrote:
>
> >Consider the Internet-draft that would allow all IP addresses to be
> >created and used dynamically. Addresses would be created primarily by
> >using global positioning (latitude-longitude-altitude) information
> >coupled with MAC addresses (network interface card manufacturer/serial
> >numbers).
>
> Well, I am quite sure that the people in my company who sell these GPS
> beasties would be pleased to see it to everyone who needs an IP address
> this way! :-)
>
> Does this mean that if I am in an airplane, my IP address would change
> REALLY REALLY FAST?
Or what happens when I swap the locations of the two
workstations on my desk? Or when I swap the two
ethernet interfaces in one of them? Or if I just
_rotate_ a multihomed host?
Jens
--
SIGSIG -- signature too long (core dumped)
Received: from ietf.org by ietf.org id aa04242; 30 Jul 96 9:58 EDT
Received: from localhost by ietf.org id aa03507; 30 Jul 96 9:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mhtml at segate.sunet.se
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mhtml-info-02.txt
Date: Tue, 30 Jul 1996 09:38:36 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607300938.aa03507 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MIME Encapsulation of
Aggregate HTML Documents Working Group of the IETF.
Title : Sending HTML in E-mail, an informational supplement to
RFC ???: MIME E-mail Encapsulation of Aggregate HTML
Documents (MHTML)
Author(s) : J. Palme
Filename : draft-ietf-mhtml-info-02.txt
Pages : 11
Date : 07/29/1996
The memo "MIME E-mail Encapsulation of Aggregate HTML Documents (MHTML)"
(draft-ietf-mhtml-spec-00.txt) specifies how to send packaged aggregate
HTML objects in MIME e-mail. This memo is an accompanying informational
document, intended to be an aid to developers. This document is not an
Internet standard.
Issues discussed are implementation methods, caching strategies, making
messages suitable both for mailers which can and which cannot handle
Multipart/related and handling recipients which do not have full Internet
connectivity.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mhtml-info-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mhtml-info-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mhtml-info-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960729134519.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mhtml-info-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mhtml-info-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960729134519.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04246; 30 Jul 96 9:58 EDT
Received: from localhost by ietf.org id aa03535; 30 Jul 96 9:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-yergeau-utf8-01.txt
Date: Tue, 30 Jul 1996 09:38:49 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607300938.aa03535 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : UTF-8, a transformation format of Unicode and ISO 10646
Author(s) : F. Yergeau
Filename : draft-yergeau-utf8-01.txt
Pages : 6
Date : 07/29/1996
The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly define
a 16 bit character set which encompasses most of the world's writing
systems. 16-bit characters, however, are not compatible with many current
applications and protocols, and this has led to the development of a few
so-called UCS transformation formats (UTF), each with different
characteristics. UTF-8, the object of this memo, has the characteristic of
preserving the full US-ASCII range: US-ASCII characters are encoded in one
octet having the usual US-ASCII value, and any octet with such a value can
only be an US-ASCII character. This provides compatibility with file
systems, parsers and other software that rely on US-ASCII values but are
transparent to other values.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-yergeau-utf8-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-yergeau-utf8-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-yergeau-utf8-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960729135758.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-yergeau-utf8-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-yergeau-utf8-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960729135758.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04538; 30 Jul 96 9:58 EDT
Received: from ietf.org by ietf.org id aa04244; 30 Jul 96 9:58 EDT
Received: from localhost by ietf.org id aa03508; 30 Jul 96 9:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mhtml at segate.sunet.se
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mhtml-spec-02.txt
Date: Tue, 30 Jul 1996 09:38:37 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607300938.aa03508 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MIME Encapsulation of
Aggregate HTML Documents Working Group of the IETF.
Title : MIME E-mail Encapsulation of Aggregate Documents,
such as HTML (MHTML)
Author(s) : J. Palme, A. Hopman
Filename : draft-ietf-mhtml-spec-02.txt
Pages : 17
Date : 07/29/1996
Although HTML [RFC 1866] was designed within the context of MIME, more than
the specification of HTML as defined in RFC 1866 is needed for two
electronic mail user agents to be able to interoperate using HTML as a
document format. These issues include the naming of objects that are
normally referred to by URIs, and the means of aggregating objects that go
together. This document describes a set of guidelines that will allow
conforming mail user agents to be able to send, deliver and display these
objects, such as HTML objects, that can contain links represdented by URIs.
In order to be able to handle inter-linked objects, the document proposes
to use the MIME type multipart/related and specifies the MIME
content-headers "Content-Location" and "Content-Base".
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mhtml-spec-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mhtml-spec-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mhtml-spec-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960729135158.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mhtml-spec-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mhtml-spec-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960729135158.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa10488; 30 Jul 96 14:33 EDT
Received: from localhost by ietf.org id aa10236; 30 Jul 96 14:28 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: IRTF Research Group Guidelines and Procedures to BCP
Reply-to: iesg at ietf.org
Date: Tue, 30 Jul 1996 14:28:40 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9607301428.aa10236 at ietf.org>
The IESG has received a request to consider IRTF Research Group
Guidelines and Procedures <draft-weinrib-irtf-guidelines-00.txt> as a
Best Current Practices document. This document is not the product of
an IETF Working Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by August 30, 1996.
Received: from ietf.org by ietf.org id aa12169; 30 Jul 96 15:27 EDT
Received: from cnri by ietf.org id aa12165; 30 Jul 96 15:27 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11792;
30 Jul 96 15:27 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <SAA17037 at pad-thai.cam.ov.com>; Tue, 30 Jul 1996 18:52:38 GMT
Received: from relay.hp.com by MIT.EDU with SMTP
id AA08333; Tue, 30 Jul 96 14:52:30 EDT
Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP
(1.37.109.16/15.5+ECS 3.3) id AA094252745; Tue, 30 Jul 1996 11:52:26 -0700
Message-Id: <199607301852.AA094252745 at relay.hp.com>
Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com
id AA161102744; Tue, 30 Jul 1996 14:52:24 -0400
To: "Guangxing (G.) Li" <Guangxing.Li.0501756 at nortel.co.uk>
Cc: cat-ietf at mit.edu
Subject: Re: a comment about gssv2-cbind
In-Reply-To: Guangxing.Li.0501756's message of Wed, 24 Jul 1996 11:19:36 +0100.
<9607241020.AA25633 at MIT.EDU>
Date: Tue, 30 Jul 1996 14:52:24 -0400
Sender:ietf-archive-request at ietf.org
From: Bill Sommerfeld <sommerfeld at apollo.hp.com>
> while using gss_wrap and gss_unwrap to write a secure session application,
> I find I have to keep copying the values of gss_buffer_t to
> my application buffers and releasing the gss_buffers.
> This sort of activity is believed to be unnecessary and time consuming
> in real-time communication systems.
If you're using cryptography implemented in software, the cost of the
cryptographic primitives is going to be much larger than the cost of
the data copy.
If you're running on UNIX and want to avoid copies, you can use writev
or sendmsg to do scatter/gather at the user-space/kernel-space
boundary.
- Bill
Received: from ietf.org by ietf.org id aa20029; 30 Jul 96 22:55 EDT
Received: from cnri by ietf.org id aa19909; 30 Jul 96 22:48 EDT
Received: from daryl.scsn.net by CNRI.Reston.VA.US id aa17154;
30 Jul 96 22:48 EDT
Received: from usa1.moneyworld.com ([208.129.19.69]) by daryl.scsn.net (8.6.12/8.6.9) with SMTP id WAA05659 for <ietf-123 at cnri.reston.va.us>; Tue, 30 Jul 1996 22:50:24 -0400
Date: Tue, 30 Jul 1996 22:50:24 -0400
Sender:ietf-announce-request at ietf.org
From: health at moneyworld.com
Message-Id: <199607310250.WAA05659 at daryl.scsn.net>
To: ietf-123 at CNRI.Reston.VA.US
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Reply-to: health at moneyworld.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: Scientific Discoveries Minimize Aging (DHEA)
http://dhea.natureplus.com
Scientific results show the amazing benefits of DHEA in the search for
the FOUNTAIN OF YOUTH. Regain the eye of the tiger. Create your own
INDEPENDENCE DAY! People, age 70, feeling and acting 25. Read the medical
research, then laugh.
http://dhea.natureplus.com
Bob Williams 206-269-0846
To terminate from my Health Catalog, Reply to health at moneyworld.com with
"remove" in the subject field.
P.S. You many find my full line Vitamin, Supplements and OTC Health Catalog at
http://natureplus.com.
Received: from ietf.org by ietf.org id aa02180; 31 Jul 96 8:48 EDT
Received: from cnri by ietf.org id aa02176; 31 Jul 96 8:48 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06247;
31 Jul 96 8:48 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <MAA26795 at pad-thai.cam.ov.com>; Wed, 31 Jul 1996 12:09:01 GMT
Received: from mail13.digital.com by MIT.EDU with SMTP
id AA17362; Wed, 31 Jul 96 08:08:59 EDT
Received: from us1rmc.bb.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV)
id IAA01136; Wed, 31 Jul 1996 08:01:55 -0400 (EDT)
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA06139; Wed, 31 Jul 96 08:02:51 -0400
Message-Id: <9607311202.AA06139 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Wed, 31 Jul 96 08:02:51 EDT
Date: Wed, 31 Jul 96 08:02:51 EDT
Sender:ietf-archive-request at ietf.org
From: "John Wray, Digital DPE, (508) 486-5210 31-Jul-1996 0746" <wray at tuxedo.enet.dec.com>
To: marc at mit.edu
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, marc at mit.edu
Subject: Re: gss_import_name...
A long time ago, Mark wrote:
>>> In RFC 1961 (GSS-API w/Socks5), they say:
>>>
>>> The client should call gss_import_name to obtain an internal
>>> representation of the server name. For maximal portability
>>> the default name_type GSS_C_NULL_OID should be used to specify
>>> the default name space, and the input name_string should
>>> treated by the client's code as an opaque name-space specific
>>> input.
>>>
>>> Which of course tries to allocate & copy the name. Problem is the name
>>> is NULL, so on the copy, I get a seg fault. Is this a problem in beta6,
>>> or an oversight in the RFC? If that's the case, what should go there?
>
>Neither rfc1508 nor draft-ietf-cat-gssv2-06.txt (which is supposed to
>advance to proposed, but is still in rfc-editor-wait) mentions the
>validity of NULL to indicated a default name type, and I believe this
>is correct. However, rfc1509 does describe the validity of NULL.
>This is a conflict, and I believe the base specification gets it
>right.
I don't think we should remove the use of GSS_C_NULL_OID to indicate the use of
a default namespace. We need a portable way of asking for default behavior.
The intended use for this is where the input name is given directly by the
user. Supplying GSS_C_NULL_OID allows the application to tell the GSSAPI
implementation "figure out the nametype yourself", and the GSSAPI
implementation is allowed to use whatever platform-specific knowledge is
available to it. Without this feature, either the user would have to
explicitly specify a namespace, or the application would have to do the
figuring out, or the application would have to mandate a particular namespace.
The latter would either limit the portability of the application (if the
namespace choice is hard-coded), or require that the application's default
namespace be configurable. If GSSAPI is allowed to make this determination,
then you only have to configure GSSAPI, rather than having to configure each
application individually.
The application can still make the determination if it wishes - but mandating
that GSSAPI implementations support the concept of a default namespace
identifier allows applications to delegate this task to GSSAPI.
I don't see the use of GSS_C_NULL_OID as a conflict between the base spec and
the C bindings, but if this appears to be a problem, an alternative would be to
define an OID within gssapi.h that means "local default".
John
Received: from ietf.org by ietf.org id aa03456; 31 Jul 96 9:29 EDT
Received: from localhost by ietf.org id aa02854; 31 Jul 96 9:19 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-perkins-rtp-redundancy-01.txt, .ps
Date: Wed, 31 Jul 1996 09:19:01 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607310919.aa02854 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Payload Format Issues for Redundant Encodings in RTP
Author(s) : M. Handley, V. Hardman, I. Kouvelas, C. Perkins,
J. Bolot, A. Garcia, S. Parisis
Filename : draft-perkins-rtp-redundancy-01.txt, .ps
Pages : 8
Date : 07/30/1996
This document describes a payload type for use with the real-time transport
protocol (RTP), version 2, for encoding redundant data. The primary
motivation for the scheme described herein is the development of audio
conferencing tools for use with lossy packet networks such as the Internet
Mbone, although this scheme is not limited to such applications.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-perkins-rtp-redundancy-01.txt".
Or
"get draft-perkins-rtp-redundancy-01.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-perkins-rtp-redundancy-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-perkins-rtp-redundancy-01.txt".
Or
"FILE /internet-drafts/draft-perkins-rtp-redundancy-01.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960730163702.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-perkins-rtp-redundancy-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-perkins-rtp-redundancy-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960730163702.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03452; 31 Jul 96 9:29 EDT
Received: from localhost by ietf.org id aa02838; 31 Jul 96 9:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-mime-direct-02.txt
Date: Wed, 31 Jul 1996 09:18:56 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607310918.aa02838 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : A MIME Content-Type for Directory Information
Author(s) : T. Howes, M. Smith
Filename : draft-ietf-asid-mime-direct-02.txt
Pages : 20
Date : 07/30/1996
This document defines a MIME Content-Type for holding directory
information. The definition is independent of any particular directory
service. The application/directory Content-Type is defined for holding a
variety of directory information, for example, name, or email address.
The application/directory Content-Type can also be used as the root body
part in a multipart/related Content-Type for handling more complicated
situations, especially those in which non-textual information that already
has a natural MIME representation, for example, a photograph or sound, must
be represented.
The application/directory Content-Type defines a general framework and
format for holding directory information in a simple "type: value" format.
This format is compatible with the Versit Electronic Business Card
Specification text encoding. Mechanisms are defined to specify alternate
character sets, languages, encodings and other meta-information.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-asid-mime-direct-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-mime-direct-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-mime-direct-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960730162334.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-mime-direct-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-mime-direct-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960730162334.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03445; 31 Jul 96 9:29 EDT
Received: from localhost by ietf.org id aa02802; 31 Jul 96 9:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-pppext-mppc-00.txt
Date: Wed, 31 Jul 1996 09:18:32 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607310918.aa02802 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : Microsoft Point-To-Point Compression (MPPC) Protocol
Author(s) : G. Pall
Filename : draft-ietf-pppext-mppc-00.txt
Pages : 9
Date : 07/29/1996
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and
utilize compression protocols over PPP encapsulated links.
This document describes the use of the Microsoft Point to Point
Compression protocol (also referred to as MPPC in this document)
for compressing PPP encapsulated packets.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pppext-mppc-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-mppc-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-mppc-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960729135359.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-mppc-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-mppc-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960729135359.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03449; 31 Jul 96 9:29 EDT
Received: from localhost by ietf.org id aa02940; 31 Jul 96 9:19 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ion at nexen.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ion-marsmcs-00.txt, .ps
Date: Wed, 31 Jul 1996 09:19:23 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607310919.aa02940 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internetworking Over NBMA
Working Group of the IETF.
Title : Multicast Server Architectures for
MARS-based ATM multicasting.
Author(s) : R. Talpade, M. Ammar
Filename : draft-ietf-ion-marsmcs-00.txt, .ps
Pages : 22
Date : 07/30/1996
A mechanism to support the multicast needs of layer 3 protocols in general,
and IP in particular, over UNI 3.0/3.1 based ATM networks has been
described in draft-ietf-ipatm-ipmc-12.txt. Two basic approaches exist for
the intra-subnet (intra-cluster) multicasting of IP packets. One makes use
of a mesh of point to multipoint VCs (the 'VC Mesh' approach), while the
other uses a shared point to multipoint tree rooted on a Multicast
Server (MCS). This memo provides details on the design and
implementation of an MCS, building on the core mechanisms defined in
draft-ietf-ipatm-ipmc-12.txt. It also provides a mechanism for using
multiple MCSs per group for providing fault tolerance. This approach can
be used with draft-ietf-ipatm-ipmc-12.txt based MARS server and clients,
without needing any change in their functionality.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ion-marsmcs-00.txt".
Or
"get draft-ietf-ion-marsmcs-00.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-marsmcs-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ion-marsmcs-00.txt".
Or
"FILE /internet-drafts/draft-ietf-ion-marsmcs-00.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960730165556.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-marsmcs-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-marsmcs-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960730165556.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03458; 31 Jul 96 9:29 EDT
Received: from localhost by ietf.org id aa02785; 31 Jul 96 9:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-perkins-smi-clarification-00.txt
Date: Wed, 31 Jul 1996 09:18:13 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607310918.aa02785 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Clarification of SMIv2
Author(s) : D. Perkins
Filename : draft-perkins-smi-clarification-00.txt
Pages : 12
Date : 07/30/1996
This memo is a clarification of the structure of management information
(SMI) for version 2 of the Simple Network Management Protocol (SNMP).
SMIv2 is defined in RFCs 1902[1], 1903[2] and 1904[4]. This version is a
rough first draft as requested by the SNMPv2 WG at the SMI Documentation
BOF during the June 1996 IETF.
This memo assumes that the reader has already read RFCs 1902-4 and
generally understands the concepts defined in these documents.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-perkins-smi-clarification-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-perkins-smi-clarification-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-perkins-smi-clarification-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960731091331.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-perkins-smi-clarification-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-perkins-smi-clarification-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960731091331.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03455; 31 Jul 96 9:29 EDT
Received: from localhost by ietf.org id aa02870; 31 Jul 96 9:19 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-perkins-snmpv2-lex-spec-00.txt
Date: Wed, 31 Jul 1996 09:19:07 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607310919.aa02870 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Lexical Specification for the
SNMPv2 MIB Module Language
Author(s) : D. Perkins
Filename : draft-perkins-snmpv2-lex-spec-00.txt
Pages : 32
Date : 07/30/1996
This memo integrates the specifications for the lexical elements of the MIB
module language from section 8 of the ASN.1 specification[4], augmented by
the ASN.1 macros defined for the MIB module language, and modified by
textual descriptions in SMIv2(RFCs 1902[1], 1903[2] and 1904[3]); and the
standard practices found in most of the leading MIB compilers that are
accepted by the SNMP community. Also include in this memo is a Lex
specification for the tokens of the language.
This memo is a rough first draft as requested by the SNMPv2 WG
at the SMI Documentation BOF during the June 1996 IETF.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-perkins-snmpv2-lex-spec-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-perkins-snmpv2-lex-spec-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-perkins-snmpv2-lex-spec-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960730165015.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-perkins-snmpv2-lex-spec-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-perkins-snmpv2-lex-spec-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960730165015.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03460; 31 Jul 96 9:29 EDT
Received: from localhost by ietf.org id aa02966; 31 Jul 96 9:19 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-martins-forums-00.txt
Date: Wed, 31 Jul 1996 09:19:52 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607310919.aa02966 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Internet Discussion Forum Protocol (IDFP)
Author(s) : L. Martins
Filename : draft-martins-forums-00.txt
Pages : 10
Date : 07/30/1996
This document presents a new alternative way of implementing discussion
forums other than NNTP and mailing lists. It is largely based on standard
e-mail except for retrieval. The purpose of this new protocol is to
atenuate the bandwidth and net resources needed by either NNTP and mailing
lists.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-martins-forums-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-martins-forums-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-martins-forums-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960730170636.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-martins-forums-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-martins-forums-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960730170636.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03583; 31 Jul 96 9:29 EDT
Received: from ietf.org by ietf.org id aa03442; 31 Jul 96 9:29 EDT
Received: from localhost by ietf.org id aa02819; 31 Jul 96 9:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-mityok-macbin1-01.txt
Date: Wed, 31 Jul 1996 09:18:48 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9607310918.aa02819 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Adopt MacBinary II Mac File Encoding for FTP Transfers
Author(s) : T. Mityok
Filename : draft-mityok-macbin1-01.txt
Pages : 2
Date : 07/30/1996
This draft is a targeted at the Macintosh Internet users to adopt the
MacBinary II form of Macintosh file encoding for use on FTP sites as an
alternative to BinHexing Macintosh files.
The current standard file encoding method for Macintosh files placed on
Internet FTP sites is BinHexing. The process converts binary data into a
coded-text based format. While very popular and widely used this process
increases the files size dramatically.
For example a self-extracting archive that is 389,089 byte in size will
swell to 535,944 bytes after being BinHexed. The resulting file is nearly
30% larger than its original version. This process is completely wasteful
and totally unnecessary for FTP transfers.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-mityok-macbin1-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-mityok-macbin1-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-mityok-macbin1-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960730161348.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-mityok-macbin1-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-mityok-macbin1-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960730161348.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08220; 31 Jul 96 11:14 EDT
Received: from localhost by ietf.org id aa07891; 31 Jul 96 11:06 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: tcplw at bsdi.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Protocol Action: TCP Selective Acknowledgment Options to Proposed
Standard
Date: Wed, 31 Jul 1996 11:06:17 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9607311106.aa07891 at ietf.org>
The IESG has approved the Internet-Draft "TCP Selective Acknowledgment
Options" <draft-ietf-tcplw-sack-02.txt> as a Proposed Standard. This
document is the product of the TCP Large Windows Working Group. The IESG
contact person is Allison Mankin.
Technical Summary
The requirements for an efficient selective acknowledgement (SACK)
extension to TCP were first presented in RFC 1072. When multiple
packets are lost from one window of data, the TCP often experiences
unneeded loss of throughput. A SACK mechanism combined with a suitable
retransmission policy can help to improve performance.
The document specifies two backward-compatible options for extending
TCP with SACK, and describes recommended behavior of TCP receivers and
senders using SACK.
Working Group Summary
The TCP Large Windows Working Group addressed a BOF and an official
meeting to this topic. There was extensive review and strong working
group consensus on the specification. IETF Last Call identified no
problems or concerns.
Protocol Quality
The protocol was reviewed for the IESG by Allison Mankin, the Transport
Services Area Director. Mathis and Mahdavi implemented and tested the
specification as they wrote. A publicly available reference
implementation was done as well, and lessons learned from it were
presented to the Working Group and incorporated before Last Call.
Received: from ietf.org by ietf.org id aa09659; 31 Jul 96 12:08 EDT
Received: from cnri by ietf.org id aa09655; 31 Jul 96 12:08 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09247;
31 Jul 96 12:08 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <PAA06219 at pad-thai.cam.ov.com>; Wed, 31 Jul 1996 15:34:41 GMT
Received: from eurogate.nortel.co.uk by MIT.EDU with SMTP
id AA25625; Wed, 31 Jul 96 11:34:37 EDT
Message-Id: <9607311534.AA25625 at MIT.EDU>
Received: from hedera.bnr.co.uk (actually innergate.nortel.co.uk)
by eurogate.nortel.co.uk with SMTP (PP);
Wed, 31 Jul 1996 16:31:04 +0100
Received: from bhars7a1.bnr.co.uk by hedera.bnr.co.uk with SMTP (PP);
Wed, 31 Jul 1996 15:30:53 +0000
To: Bill Sommerfeld <sommerfeld at apollo.hp.com>
Cc: cat-ietf at mit.edu
Subject: Re: a comment about gssv2-cbind
In-Reply-To: Your message of "Tue, 30 Jul 1996 14:52:24 EDT." <199607301852.AA094252745 at relay.hp.com>
Date: Wed, 31 Jul 1996 16:30:50 +0100
Sender:ietf-archive-request at ietf.org
From: "Guangxing (G.) Li" <Guangxing.Li.0501756 at nortel.co.uk>
> From: Bill Sommerfeld <sommerfeld at apollo.hp.com>
>
> > while using gss_wrap and gss_unwrap to write a secure session application,
> > I find I have to keep copying the values of gss_buffer_t to
> > my application buffers and releasing the gss_buffers.
> > This sort of activity is believed to be unnecessary and time consuming
> > in real-time communication systems.
>
> If you're using cryptography implemented in software, the cost of the
> cryptographic primitives is going to be much larger than the cost of
> the data copy.
true, but this is not a reason for not helping applications to avoid
data copy.
> If you're running on UNIX and want to avoid copies, you can use writev
> or sendmsg to do scatter/gather at the user-space/kernel-space
> boundary.
yes you can do that, but this is not convenient, applications still
have to remember/release the gss buffer (so does the gss mechanism).
>- Bill
-Guangxing/George
Received: from ietf.org by ietf.org id aa10959; 31 Jul 96 12:42 EDT
Received: from localhost by ietf.org id aa10631; 31 Jul 96 12:38 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ip-atm at matmos.hpl.hp.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.orgcnri.reston.va.us>
Subject: Protocol Action: Support for Multicast over UNI 3.0/3.1 based ATM
Networks. to Proposed Standard
Date: Wed, 31 Jul 1996 12:38:02 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9607311238.aa10631 at ietf.org>
The IESG has approved the Internet-Draft "Support for Multicast over UNI
3.0/3.1 based ATM Networks." <draft-ietf-ipatm-ipmc-12.txt> as a Proposed
Standard. This document is the product of the IP Over Asynchronous
Transfer Mode Working Group. The IESG contact persons are Frank
Kastenholz and Jeffrey Burgan.
Technical Summary
This protocol provides multicast support over ATM networks for IP
hosts. It operates by defining a multicast server. The multicast
server operates in one of two modes. In the first mode it provides the
ATM address of each node in a multicast group (in which case the node
sending the multicast uses a point-to-multipoint VC to transmit a
multicast datagram to all recipients). In the second mode, the server
performs the actual multicast distribution; nodes send their multicast
packets to the server, which then distributes the multicast packets to
all members of the multicast group. In all cases, nodes wishing to
receive packets for a specific multicast group must register with the
multicast server.
Working Group Summary
This protocol is a product of the IP/ATM working group. There was no
significant dissent in the working group. No comments were received
during the IETF last call.
Protocol Quality
This protocol has been reviewed for the IESG by Frank Kastenholz and
Jeffrey Burgan.
Received: from ietf.org by ietf.org id aa11188; 31 Jul 96 12:45 EDT
Received: from localhost by ietf.org id aa11122; 31 Jul 96 12:44 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: rmonmib at cisco.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Protocol Action: Remote Network Monitoring MIB Protocol
Identifiers to Proposed Standard
Date: Wed, 31 Jul 1996 12:44:27 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9607311244.aa11122 at ietf.org>
The IESG has approved the following two Internet-Drafts:
1. Remote Network Monitoring Management Information Base version 2
<draft-ietf-rmonmib-rmonmib-v2-03.txt>
2. Remote Network Monitoring MIB Protocol Identifiers
<draft-ietf-rmonmib-rmonprot-03.txt>
as Proposed Standards. These documents are the product of the Remote
Network Monitoring Working Group. The IESG contact person is Deirdre
Kostick.
Technical Summary
The Remote Network Monitoring MIB (RMON) as defined in RFC 1757,
provides an NMS with mechanisms to monitor and collect large amounts
of data about the traffic utilization of particular subnetworks, by
promiscuously monitoring the MAC frames transmitted onto those
subnetworks.
RMON-2 builds upon the RFC 1757 standard, enabling several network
management functions, such as fault monitoring, application monitoring,
capacity and network planning, and remote polling.
The new MIB extends many monitoring capabilities beyond the MAC
layer, up through the application layer. Numerous improvements such
as probe configuration, better resource management, and faster table
uploads, have also been made to increase the robustness and
interoperability of RMON implementations.
Working Group Summary
The process of evaluating and selecting a subset of features for
development out of the many different proposals was the most
contentious aspect of the WG effort.
The following features were the least contentious:
* extend the basic RMON-1 functions beyond the MAC layer
* use a centralized protocol directory architecture
* add user-specified history collection
* reduce table retrieval times
* increase NMS control of probe resources
* add a trap destination table for RMON traps
These features were more contentious:
* include application-layer matrix-topN-reporting
* improve RMON filtering capabilities
* include general probe configuration capabilities
The MIB and Protocol Identifiers documents reflect the consensus of
the Working Group.
Protocol Quality
The RMON-2 MIB and RMON Protocol Identifiers documents were reviewed
for the IETF NM Area by Jeff Johnson, and for the IESG by Deirdre
Kostick.
Received: from ietf.org by ietf.org id aa11295; 31 Jul 96 12:48 EDT
Received: from localhost by ietf.org id aa11242; 31 Jul 96 12:46 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Document Action: PPP Stac LZS Compression Protocol to
Informational
Date: Wed, 31 Jul 1996 12:46:39 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9607311246.aa11242 at ietf.org>
The IESG has reviewed the Internet-Draft "PPP Stac LZS Compression
Protocol" <draft-ietf-pppext-stacker-10.txt> and recommends that it be
published by the RFC Editor as an Informational RFC. This document is the
product of the Point-to-Point Protocol Extensions Working Group. The IESG
contact persons are Frank Kastenholz and Jeffrey Burgan.
Received: from ietf.org by ietf.org id aa12997; 31 Jul 96 13:34 EDT
Received: from cnri by ietf.org id aa12993; 31 Jul 96 13:34 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10472;
31 Jul 96 13:34 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <RAA10485 at pad-thai.cam.ov.com>; Wed, 31 Jul 1996 17:00:31 GMT
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA08151; Wed, 31 Jul 96 13:00:31 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <RAA10481 at pad-thai.cam.ov.com>; Wed, 31 Jul 1996 17:00:30 GMT
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id NAA17426; Wed, 31 Jul 1996 13:00:29 -0400
Message-Id: <199607311700.NAA17426 at winkl.cam.ov.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: CAT WG Review Last-Call: draft-myers-auth-sasl-04.txt
Date: Wed, 31 Jul 1996 13:00:28 -0400
Sender:ietf-archive-request at ietf.org
From: John Linn <linn at cam.ov.com>
CAT fanciers:
Although SASL, draft-myers-auth-sasl-04.txt, isn't a formal work item
of the CAT WG, it is being suggested for Proposed Standard status, and
relates to usage and integration of security mechanisms within IETF
protocols, both via GSS-API and otherwise. It's therefore been
suggested, and I believe it to be useful and appropriate, that it
should receive review within the CAT WG.
While there was brief discussion of SASL at/around the Montreal IETF,
both at the meeting and by E-mail on the list, the number of active
commentators has so far been too limited to demonstrate major breadth
of review. Please send any comments to the CAT-WG mailing list by
Wednesday, 14 August: in addition to comments against the draft's
content, comments from WG participants who have reviewed the document
and consider it suitable for advancement would also be helpful.
Thanks, regards, ...
--jl
Received: from ietf.org by ietf.org id aa10736; 1 Aug 96 9:48 EDT
Received: from localhost by ietf.org id aa08156; 1 Aug 96 9:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-hawkinson-mboned-pruning-00.txt
Date: Thu, 01 Aug 1996 09:33:27 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608010933.aa08156 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Multicast pruning a necessity
Author(s) : J. Hawkinson
Filename : draft-hawkinson-mboned-pruning-00.txt
Pages : 2
Date : 07/31/1996
This document mandates that the MBone will be free of non-pruning
multicast implementations by 31 October 1996.
It is a product of the Multicast Deployment Working Group in the
Operational Requirements area of the Internet Engineering Task Force.
Submit comments to <mboned at ns.uoregon.edu> or the author.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-hawkinson-mboned-pruning-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hawkinson-mboned-pruning-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-hawkinson-mboned-pruning-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960731164230.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hawkinson-mboned-pruning-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hawkinson-mboned-pruning-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960731164230.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12272; 1 Aug 96 9:48 EDT
Received: from ietf.org by ietf.org id aa10747; 1 Aug 96 9:48 EDT
Received: from localhost by ietf.org id aa08299; 1 Aug 96 9:36 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-calhoun-vtp-ext-l2-00.txt
Date: Thu, 01 Aug 1996 09:36:52 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608010936.aa08299 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Virtual Tunnel Protocol Layer 2 Protocol Extension
Author(s) : P. Calhoun
Filename : draft-calhoun-vtp-ext-l2-00.txt
Pages : 36
Date : 07/31/1996
The VTP Protocol specification defines a generic tunneling mechanism, as
well as extensions for IP and IPX protocols. This specification will detail
a method to establish Level 2 (PPP and SLIP) tunnels between two peers.
This strawman proposal is intended as a recommendation for using VTP as a
generic all-purpose tunnel scheme, as opposed to having multiple tunneling
mechanism for layer 2 and 3 protocols.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-calhoun-vtp-ext-l2-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-calhoun-vtp-ext-l2-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-calhoun-vtp-ext-l2-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960731161926.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-calhoun-vtp-ext-l2-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-calhoun-vtp-ext-l2-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960731161926.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12296; 1 Aug 96 9:48 EDT
Received: from ietf.org by ietf.org id aa10734; 1 Aug 96 9:48 EDT
Received: from localhost by ietf.org id aa08810; 1 Aug 96 9:44 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: vgmib at hprnd.rose.hp.com
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-vgmib-repeater-dev-02.txt
Date: Thu, 01 Aug 1996 09:44:35 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608010944.aa08810 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the 100VG-AnyLAN MIB Working
Group of the IETF.
Title : Definitions of Managed Objects for
IEEE 802.12 Repeater Devices
Author(s) : J. Flick
Filename : draft-ietf-vgmib-repeater-dev-02.txt
Pages : 54
Date : 07/31/1996
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing network
repeaters based on IEEE 802.12.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-vgmib-repeater-dev-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-vgmib-repeater-dev-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-vgmib-repeater-dev-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960731101758.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-vgmib-repeater-dev-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-vgmib-repeater-dev-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960731101758.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12290; 1 Aug 96 9:48 EDT
Received: from ietf.org by ietf.org id aa10719; 1 Aug 96 9:48 EDT
Received: from localhost by ietf.org id aa08634; 1 Aug 96 9:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-waters-reduce-isdn-costs-00.txt
Date: Thu, 01 Aug 1996 09:43:00 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608010943.aa08634 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Reducing the ISDN costs of Network Applications
that use TCP/IP.
Author(s) : S. Waters
Filename : draft-waters-reduce-isdn-costs-00.txt
Pages : 11
Date : 07/31/1996
This document discusses TCP/IP traffic on ISDN links and makes
recommendations to Network Application and Router developers with a view to
reducing the cost of using ISDN.
This topic is partly related to current activity in the PPP Working Group
on controls for Protocol Spoofing, but mainly targets the developers of
Network software such as Resource Sharing protocols, for example Network
Service and Directory Sharing.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-waters-reduce-isdn-costs-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-waters-reduce-isdn-costs-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-waters-reduce-isdn-costs-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960731135543.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-waters-reduce-isdn-costs-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-waters-reduce-isdn-costs-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960731135543.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20984; 1 Aug 96 10:20 EDT
Received: from localhost by ietf.org id aa08697; 1 Aug 96 9:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-warwick-tokenring-00.txt
Date: Thu, 01 Aug 1996 09:43:29 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608010943.aa08697 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Dedicated Token Ring Interface MIB
Author(s) : K. Lee, T. Warwick
Filename : draft-warwick-tokenring-00.txt
Pages : 33
Date : 07/31/1996
This document contains an extract from Draft 4.1 of the IEEE standard
802.5R "Dedicated Token Ring". The extract comprises the Interface MIB
for the Dedicated Token Ring interface, in SNMPv2 format.
802.5R is a standard that encompasses the existing 802.5 token-passing
method of operation, and also defines a new duplex method of operation
for use only on dedicated point to point links, that does not use tokens
for data transmission.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-warwick-tokenring-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-warwick-tokenring-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-warwick-tokenring-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960731104050.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-warwick-tokenring-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-warwick-tokenring-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960731104050.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18432; 2 Aug 96 0:18 EDT
Received: from cnri by ietf.org id aa18049; 1 Aug 96 23:59 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa00793;
1 Aug 96 23:59 EDT
Received: from usa1.moneyworld.com ([208.129.19.69]) by venera.isi.edu (5.65c/5.61+local-25)
id <AA11207>; Thu, 1 Aug 1996 20:59:29 -0700
Date: Thu, 1 Aug 1996 20:59:29 -0700
Message-Id: <199608020359.AA11207 at venera.isi.edu>
To: ietf at isi.edu
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: health at moneyworld.com
Reply-To: health at moneyworld.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: Scientific Discoveries Minimize Aging (DHEA)
Source-Info: From (or Sender) name not authenticated.
http://dhea.natureplus.com
Take advantage of the amazing benefits of DHEA. In the search for the
FOUNTAIN OF YOUTH, DHEA is a must README. People, age 70, feeling and
acting 25.
Read the medical research at http://dhea.natureplus.com .A quote from
an article published by the New York Academy of Science written by Dr.
S.S.C.YEN;
"DHEA in appropriate replacement doses appears to have remedial effects
with respect to its ability to induce an anabolic growth factor, increase
muscle strength and lean body mass, activate immune function, and enhance
quality of life in aging men and women, with no significant adverse effects."
Regain the eye of the tiger! Don't wait ! Click on: http://dhea.natureplus.com
To terminate from the Health Catalog, Reply to health at moneyworld.com with
"remove" in the subject field. Bob Williams 206-269-0846
P.S. You will find a full line of Vitamin, Supplements and OTC Health
Catalog at http://natureplus.com.
Received: from ietf.org by ietf.org id aa18660; 2 Aug 96 0:32 EDT
Received: from cnri by ietf.org id aa18612; 2 Aug 96 0:30 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa01271; 2 Aug 96 0:30 EDT
Received: from westie.gi.net by venera.isi.edu (5.65c/5.61+local-25)
id <AA12016>; Thu, 1 Aug 1996 21:30:55 -0700
Received: (from alan at localhost) by westie.gi.net (8.7.5/8.7.1) id XAA26640; Thu, 1 Aug 1996 23:27:39 -0500 (CDT)
Sender:ietf-request at ietf.org
From: Alan Hannan <alan at gi.net>
Message-Id: <199608020427.XAA26640 at westie.gi.net>
Subject: Re: Scientific Discoveries Minimize Aging (DHEA)
To: health at moneyworld.com
Date: Thu, 1 Aug 1996 23:27:38 -0500 (CDT)
Cc: ietf at isi.edu
In-Reply-To: <199608020359.AA11207 at venera.isi.edu> from "health at moneyworld.com" at Aug 1, 96 08:59:29 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Which working group does this fall under?
-alan
......... health at moneyworld.com is rumored to have said:
]
] http://dhea.natureplus.com
]
] Take advantage of the amazing benefits of DHEA. In the search for the
] FOUNTAIN OF YOUTH, DHEA is a must README. People, age 70, feeling and
] acting 25.
]
] Read the medical research at http://dhea.natureplus.com .A quote from
] an article published by the New York Academy of Science written by Dr.
] S.S.C.YEN;
] "DHEA in appropriate replacement doses appears to have remedial effects
] with respect to its ability to induce an anabolic growth factor, increase
] muscle strength and lean body mass, activate immune function, and enhance
] quality of life in aging men and women, with no significant adverse effects."
]
] Regain the eye of the tiger! Don't wait ! Click on: http://dhea.natureplus.com
]
] To terminate from the Health Catalog, Reply to health at moneyworld.com with
] "remove" in the subject field. Bob Williams 206-269-0846
]
] P.S. You will find a full line of Vitamin, Supplements and OTC Health
] Catalog at http://natureplus.com.
]
Received: from ietf.org by ietf.org id aa19058; 2 Aug 96 0:37 EDT
Received: from cnri by ietf.org id aa18986; 2 Aug 96 0:37 EDT
Received: from mailhost2.cac.washington.edu by CNRI.Reston.VA.US id aa01365;
2 Aug 96 0:37 EDT
Received: from UW-Gateway.Panda.COM by mailhost2.cac.washington.edu
(5.65+UW96.06/UW-NDC Revision: 2.33 ) id AA05392;
Thu, 1 Aug 96 21:37:07 -0700
Date: Thu, 1 Aug 1996 21:37:05 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Mark Crispin <mrc at panda.com>
To: Internet Engineering Task Force <ietf at CNRI.Reston.VA.US>
Subject: spam message from health at moneyworld.com
Message-Id: <Pine.NXT.3.95.960801211934.19910A-100000 at Ikkoku-Kan.Panda.COM>
Organization: Pandamonium Reigns
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Moneyworld.com just attacked the IETF mailing list with an advertisement
for vitamins. This domain is owned by one William C. Newell d/b/a/
Financial Connections Inc., 2508 5th Ave Suite 104, Seattle, WA 98121.
This is not the William C. Newell listed in the Seattle phone book.
It is useless to complain to moneyworld.com's administrators, since those
administrators themselves are the problem. ISP service is provided by MCI
(which has promised to terminate their service) and by BBN Planet (which
has not yet responded to complaints).
There is a complaint on file about Newell's activities at the Washington
State Attorney General's office. Please write to:
Kellie King
Consumer Representative
Consumer Protection Division
Attorney General of Washington
900 Fourth Avenue #2000
Seattle, WA 98164-1012
and reference file # 10-96-12786. The more people who write, the better
the chance there is of having the AG's office take the complaint seriously
and shutting down this operation.
Received: from ietf.org by ietf.org id aa19129; 2 Aug 96 0:40 EDT
Received: from cnri by ietf.org id aa19092; 2 Aug 96 0:39 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa01401; 2 Aug 96 0:39 EDT
Received: from cactus.slab.ntt.jp by venera.isi.edu (5.65c/5.61+local-25)
id <AA12353>; Thu, 1 Aug 1996 21:39:56 -0700
Received: by cactus.slab.ntt.jp (4.1/core*slab.mx8+)
id AA05280; Fri, 2 Aug 96 13:38:14 JST
Date: Fri, 2 Aug 96 13:38:14 JST
Sender:ietf-request at ietf.org
From: Paul Francis <francis at cactus.slab.ntt.jp>
Message-Id: <9608020438.AA05280 at cactus.slab.ntt.jp>
To: alan at gi.net, health at moneyworld.com
Subject: Re: Scientific Discoveries Minimize Aging (DHEA)
Cc: ietf at isi.edu
Source-Info: From (or Sender) name not authenticated.
Which working group does this fall under?
IPng.
PF
Received: from ietf.org by ietf.org id aa21075; 2 Aug 96 4:38 EDT
Received: from cnri by ietf.org id aa21071; 2 Aug 96 4:38 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa03628; 2 Aug 96 4:38 EDT
Received: from ietf.org by ietf.org id aa21061; 2 Aug 96 4:38 EDT
Received: from apnic.hq.unu.edu by ietf.org id aa21045; 2 Aug 96 4:37 EDT
Received: by dragon.jp.apnic.net; id RAA08277; Fri, 2 Aug 1996 17:27:09 +0900
Received: from moonsky.jp.apnic.net(10.0.10.4) by dragon.jp.apnic.net via smap (g3.0.3)
id xma008271; Fri, 2 Aug 96 17:27:07 +0900
Received: from apnic.net (davidc at localhost) by moonsky.jp.apnic.net (8.7.1/8.7.1) with ESMTP id RAA11215; Fri, 2 Aug 1996 17:33:00 +0900 (JST)
Message-Id: <199608020833.RAA11215 at moonsky.jp.apnic.net>
X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs
To: Scott Bradner <sob at newdev.harvard.edu>
cc: cidrd at iepg.org, iesg at ietf.org, ietf at ietf.org
Subject: Re: IESG review of draft-hubbard-registry-guidelines-03.txt
In-reply-to: Your message of "Thu, 01 Aug 1996 07:35:25 -0400."
<199608011135.HAA02308 at newdev.harvard.edu>
Date: Fri, 02 Aug 1996 17:32:59 +0900
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: "David R. Conrad" <davidc at apnic.net>
Hi,
It would appear there is some confusion, no doubt entirely on my part.
I had thought the term "Best Current Practice" was to denote a
document which described the practices currently in use that had been
tested under the "rough consensus/working code" philosophy, not how
some members of the IETF or IESG would like things to be.
The document in question fairly accurately describes existing registry
practices, regardless of whether those practices are "good" or not.
The practices currently in use by the Internet registry system have
evolved (painfully) over time at the demands of multiple camps with
widely varying, even diametrically opposed viewpoints. I am the first
to admit that I find many of these practices unfortunate and in need
of change, thus I have asked for the creation of a working group which
looks specifically at how the Internet registry system should evolve.
However, given some members of the IESG apparently feel, perhaps in
the perceived tradition of OSI standards, that the document should be
politically correct and include everybody's viewpoint instead of
dealing with reality as it is today, I request my name be removed from
the authors list of the draft and its possible subsequent RFC in
whatever category the remaining authors see fit to pursue (if they
feel it worthwhile to continue) -- I have neither the time nor the
interest in spending another year or two coming up with "polite in
mixed company" ways of saying things and arguing about hierarchical
addressing, why geographic addressing won't work given the current
Internet topology and why the topology is the way it is, whether or
not the registry actions are "legal" and who is liable for those
actions, how automagical addressing and/or IPv6 will save the world
from the evil registries, how the registries really aren't evil greedy
bastards err, sorry, evil greedy mindless bureaucrats attempting to
screw small ISPs for the sheer perverse hell of it, etc. etc. yet
again.
Been there, done that.
Obviously, there is a fundamental difference of opinion between the
people who run the "core" networks and the people who attach to that
"core" on what address assignment practices are essential to the
continued growth of the Internet. The registries have been caught in
the middle of the resulting battle with each side demanding we look
out for their interests regardless of our ability to do so or the
possible impact their interests would have on the Internet.
This has gotten old.
Given the registries are merely the people trying to do the "best
thing for the Internet" and implementing policy instead of creating
it, I would politely suggest the IESG produce a document describing
what the registry policies are, publish it as a BCP, and I'm sure the
registries will be happy to implement it. In the interim, I guess
we'll all just have to make up things as we go along since it would
seem unlikely the registries can document their procedures within the
IETF.
Regards,
-drc
Received: from ietf.org by ietf.org id aa21888; 2 Aug 96 6:01 EDT
Received: from cnri by ietf.org id aa21884; 2 Aug 96 6:01 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa04387; 2 Aug 96 6:01 EDT
Received: from ietf.org by ietf.org id aa21877; 2 Aug 96 6:01 EDT
Received: from munnari.OZ.AU by ietf.org id aa21862; 2 Aug 96 6:01 EDT
Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56)
id KA16192; Fri, 2 Aug 1996 20:00:25 +1000 (from kre at munnari.OZ.AU)
To: "David R. Conrad" <davidc at apnic.net>
Cc: cidrd at iepg.org, iesg at ietf.org, ietf at ietf.org
Subject: Re: IESG review of draft-hubbard-registry-guidelines-03.txt
In-Reply-To: Your message of "Fri, 02 Aug 1996 17:32:59 +0900."
<199608020833.RAA11215 at moonsky.jp.apnic.net>
Date: Fri, 02 Aug 1996 20:00:19 +1000
Message-Id: <7290.838980019 at munnari.OZ.AU>
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Robert Elz <kre at munnari.oz.au>
Date: Fri, 02 Aug 1996 17:32:59 +0900
From: "David R. Conrad" <davidc at apnic.net>
Message-ID: <199608020833.RAA11215 at moonsky.jp.apnic.net>
It would appear there is some confusion, no doubt entirely on my part.
I had thought the term "Best Current Practice" was to denote a
document which described the practices currently in use that had been
tested under the "rough consensus/working code" philosophy, not how
some members of the IETF or IESG would like things to be.
Actually, I believe exactly the opposite. Forget the label, there
is still much debate (and no consensus) as to what these things
should be called.
Go read section 5 of draft-ietf-poised95-std-proc-3-06.txt
(which has been approved as the replacement of 1602, but is
yet to get through the RFC editor's queue).
The very first sentence of that is ...
The BCP subseries of the RFC series is designed to be a way to
standardize practices and the results of community deliberations
That is, it is exactly making a standard. It is different from
the STD series (partly) because there is no need for running code.
The things anticipated to need this label are typically the cases
where you simply can't have running code in advance of adopting
the standard (or practice). The poised doc itself is one of those.
But go read the entire section - and please ignore the label (at
least until some consensus is achieved on what the label shoud be).
There still seems to be an opinion, which I guess comes from people
who have een the label but not the description, that a BCP is a
"real good informational RFC". It is not.
The document in question fairly accurately describes existing
registry practices,
That tells me two things. First, the registries have started doing
this before any IETF standards blessing - ie: don't consider
themselves bound by the IETF, and if the IETF community were to
adopt a totally different approach would probably simply go on doing
what they're doing. That raises the question as to whether this
doc belongs as part of the IETF processes at all.
And second, that what is being published is information - "this is
what we do", which is (or should be) exactly what an Informational
RFC is all about.
Note this is just the same as some organisation publishing their
private protocol ("this is how we tunnel ATM packets over X.25")
as the registries publishing their practices ("this is how we
allocate IP addresses"). All of this is information for the
community, and "Informational" is what it should be.
A BCP would be a statement from the IETF of the form "this is
how XXX should be done" - just a STD where 2 implementations, and
running code before approval, doesn't really make sense.
kre
Received: from ietf.org by ietf.org id aa04292; 2 Aug 96 7:25 EDT
Received: from cnri by ietf.org id aa04288; 2 Aug 96 7:25 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa05391; 2 Aug 96 7:25 EDT
Received: from ietf.org by ietf.org id aa04279; 2 Aug 96 7:25 EDT
Received: from singapura.singnet.com.sg by ietf.org id aa04266;
2 Aug 96 7:25 EDT
Received: from localhost (mathias at localhost) by singapura.singnet.com.sg (8.7.3/8.7.2) with SMTP id TAA22753; Fri, 2 Aug 1996 19:22:08 +0800 (SST)
Date: Fri, 2 Aug 1996 19:22:06 +0800 (SST)
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Mathias Koerber <mathias at staff.singnet.com.sg>
X-Sender: mathias at singapura.singnet.com.sg
Reply-To: mathias at staff.singnet.com.sg
To: Robert Elz <kre at munnari.oz.au>
cc: "David R. Conrad" <davidc at apnic.net>, cidrd at iepg.org, iesg at ietf.org,
ietf at ietf.org
Subject: Re: IESG review of draft-hubbard-registry-guidelines-03.txt
In-Reply-To: <7290.838980019 at munnari.OZ.AU>
Message-ID: <Pine.OSF.3.93.960802191635.27807D-100000 at singapura.singnet.com.sg>
X-Disclaimer: I don't speak for anyone except for myself (and to myself
Organization: SingNet
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 2 Aug 1996, Robert Elz wrote:
| Date: Fri, 02 Aug 1996 20:00:19 +1000
| From: Robert Elz <kre at munnari.oz.au>
| To: "David R. Conrad" <davidc at apnic.net>
| Cc: cidrd at iepg.org, iesg at ietf.org, ietf at ietf.org
| Subject: Re: IESG review of draft-hubbard-registry-guidelines-03.txt
|
| Date: Fri, 02 Aug 1996 17:32:59 +0900
| From: "David R. Conrad" <davidc at apnic.net>
| Message-ID: <199608020833.RAA11215 at moonsky.jp.apnic.net>
|
| It would appear there is some confusion, no doubt entirely on my part.
| I had thought the term "Best Current Practice" was to denote a
| document which described the practices currently in use that had been
| tested under the "rough consensus/working code" philosophy, not how
| some members of the IETF or IESG would like things to be.
|
| Actually, I believe exactly the opposite. Forget the label, there
| is still much debate (and no consensus) as to what these things
| should be called.
|
| Go read section 5 of draft-ietf-poised95-std-proc-3-06.txt
| (which has been approved as the replacement of 1602, but is
| yet to get through the RFC editor's queue).
|
| The very first sentence of that is ...
|
| The BCP subseries of the RFC series is designed to be a way to
| standardize practices and the results of community deliberations
|
| That is, it is exactly making a standard. It is different from
| the STD series (partly) because there is no need for running code.
| The things anticipated to need this label are typically the cases
| where you simply can't have running code in advance of adopting
| the standard (or practice). The poised doc itself is one of those.
|
| But go read the entire section - and please ignore the label (at
| least until some consensus is achieved on what the label shoud be).
|
| There still seems to be an opinion, which I guess comes from people
| who have een the label but not the description, that a BCP is a
| "real good informational RFC". It is not.
|
| The document in question fairly accurately describes existing
| registry practices,
|
| That tells me two things. First, the registries have started doing
| this before any IETF standards blessing - ie: don't consider
| themselves bound by the IETF, and if the IETF community were to
| adopt a totally different approach would probably simply go on doing
| what they're doing. That raises the question as to whether this
| doc belongs as part of the IETF processes at all.
|
I beg to disagree..
It is called "BCP", because it documents "best CURRENT practices", ie
it does not mandate a standard at all, but gives blessing to what the
majority feels has been proven most successful and fair, and ...
If you claim that registries doing this already before the BCP are
working outside the IETF, I think you are condemning the IETF process
in total. There will always be grey ares where it is left up to
individuals or groups to formulate policy in order to implement
standards or make things work. The best of these should become
BCP *after* they have proven successful..
Ifyou want to establisg new standards w/o code, call them BRP (Best
recommended practices), or just keep with STD..
| And second, that what is being published is information - "this is
| what we do", which is (or should be) exactly what an Informational
| RFC is all about.
Again I dsagree. Informational RFC need not even document current but
only possible practices, techniques etc, to document them and maybe even
explain why they were not chosen.. (by some, all, a few, whatever)..
|
| Note this is just the same as some organisation publishing their
| private protocol ("this is how we tunnel ATM packets over X.25")
| as the registries publishing their practices ("this is how we
| allocate IP addresses"). All of this is information for the
| community, and "Informational" is what it should be.
|
| A BCP would be a statement from the IETF of the form "this is
| how XXX should be done" - just a STD where 2 implementations, and
| running code before approval, doesn't really make sense.
|
| kre
|
Mathias Koerber | Tel: +65 / 471 9820 | mathias at staff.singnet.com.sg
SingNet NOC | Fax: +65 / 475 3273 | Mathias_Koerber at pobox.org.sg
Q'town Tel. Exch. | PGP: Keyid: 768/25E082BD, finger mathias at singnet.com.sg
2 Stirling Rd | 1A 8B FC D4 93 F1 9A FC BD 98 A3 1A 0E 73 01 65
S'pore 148943 | Disclaimer: I speak only for myself
* Eifersucht ist eine Leidenschaft, die mit Eifer sucht, was Leiden schafft *
Received: from ietf.org by ietf.org id aa07545; 2 Aug 96 8:00 EDT
Received: from cnri by ietf.org id aa07540; 2 Aug 96 8:00 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa05818; 2 Aug 96 8:00 EDT
Received: from ietf.org by ietf.org id aa07522; 2 Aug 96 8:00 EDT
Received: from munnari.OZ.AU by ietf.org id aa07492; 2 Aug 96 8:00 EDT
Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56)
id LA03799; Fri, 2 Aug 1996 21:57:16 +1000 (from kre at munnari.OZ.AU)
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Robert Elz <hostmaster at munnari.oz.au>
To: mathias at staff.singnet.com.sg
Cc: cidrd at iepg.org, iesg at ietf.org, ietf at ietf.org
Subject: Re: IESG review of draft-hubbard-registry-guidelines-03.txt
In-Reply-To: Your message of "Fri, 02 Aug 1996 19:22:06 +0800."
<Pine.OSF.3.93.960802191635.27807D-100000 at singapura.singnet.com.sg>
Date: Fri, 02 Aug 1996 21:57:11 +1000
Message-Id: <7339.838987031 at munnari.OZ.AU>
X-Orig-Sender: kre at munnari.oz.au
Date: Fri, 2 Aug 1996 19:22:06 +0800 (SST)
From: Mathias Koerber <mathias at staff.singnet.com.sg>
Message-ID: <Pine.OSF.3.93.960802191635.27807D-100000 at singapura.singnet.com.sg>
It is called "BCP", because it documents "best CURRENT practices", ie
it does not mandate a standard at all, but gives blessing to what the
majority feels has been proven most successful and fair, and ...
Are you describing what you think a BCP ought to be, or what it
actually is. Have you read the (finished & approved) poised draft?
If you claim that registries doing this already before the BCP are
working outside the IETF, I think you are condemning the IETF process
in total.
No. There is very much a question of how much the IETF should
be working on what are basically policy areas - operations of the
net, the registries, the DNS, the number space, etc. It seems
there is little doubt but that the IETF is the best place to
work on the technical matters related to all of these, it is by
no means clear that the IETF is the best place to work on the
politics (policies). That is a question that has been receiving
some attention recently in several areas.
If you want to establisg new standards w/o code, call them BRP
(Best recommended practices), or just keep with STD..
As I said, what they should be called is still very much an open
question, with many opinions. For now, please forget the label,
as it is quite possible that any doc now labelled BCP will
eventually be relabelled with another acronym (or perhaps the
same acronym derived from a different source).
Please, everyone, whenever the question of "to BCP or not to BCP"
arises, please consider this against what is written in the
poised doc where the series is described, not by the label.
Again I dsagree. Informational RFC need not even document current but
only possible practices, techniques etc, to document them and maybe even
explain why they were not chosen.. (by some, all, a few, whatever)..
Sure - all of that provides information. There are lots of
different kinds of information. Current practices are one kind
of information that can be provided to the community.
It's not impossible that "real good informational" may be something
that's worth having - the poisson wg (follow on from poised'95)
is going to discuss all of this - get involved in that effort.
However, as currently defined that is not what BCP is.
Read the docs.
kre
Received: from ietf.org by ietf.org id aa08094; 2 Aug 96 8:14 EDT
Received: from cnri by ietf.org id aa08090; 2 Aug 96 8:14 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa05975; 2 Aug 96 8:14 EDT
Received: from ietf.org by ietf.org id aa08074; 2 Aug 96 8:14 EDT
Received: from puli.cisco.com by ietf.org id aa08061; 2 Aug 96 8:14 EDT
Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id FAA21338; Fri, 2 Aug 1996 05:13:30 -0700
X-Sender: bstewart at puli.cisco.com
Message-Id: <v03007801ae27a0eae444 at [171.69.128.42]>
In-Reply-To: <7339.838987031 at munnari.OZ.AU>
References: Your message of "Fri, 02 Aug 1996 19:22:06 +0800."
<Pine.OSF.3.93.960802191635.27807D-100000 at singapura.singnet.com.sg>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 2 Aug 1996 08:13:50 -0400
To: Robert Elz <hostmaster at munnari.oz.au>, mathias at staff.singnet.com.sg
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Bob Stewart <bstewart at cisco.com>
Subject: Re: IESG review of draft-hubbard-registry-guidelines-03.txt
Cc: cidrd at iepg.org, iesg at ietf.org, ietf at ietf.org
Circa 9:57 PM +1000 8/2/96, Robert Elz bitwhacked:
>As I said, what they should be called is still very much an open
>question, with many opinions. For now, please forget the label,
>as it is quite possible that any doc now labelled BCP will
>eventually be relabelled with another acronym (or perhaps the
>same acronym derived from a different source).
How long has it been since "RFC" really meant "Request for Comment?" Did
it ever? Robert's explanation of the three words behind BCP versus the
prose saying what it really means sound like good IETF tradtion.
I hate acronyms. People forget or ignore what they stand for. They're new
words with weird spelling and sometimes obscure etymology.
Bob
Received: from ietf.org by ietf.org id aa08735; 2 Aug 96 8:45 EDT
Received: from cnri by ietf.org id aa08730; 2 Aug 96 8:45 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa06344; 2 Aug 96 8:45 EDT
Received: from ietf.org by ietf.org id aa08723; 2 Aug 96 8:45 EDT
Received: from singapura.singnet.com.sg by ietf.org id aa08709;
2 Aug 96 8:45 EDT
Received: from localhost (mathias at localhost) by singapura.singnet.com.sg (8.7.3/8.7.2) with SMTP id UAA22747; Fri, 2 Aug 1996 20:44:58 +0800 (SST)
Date: Fri, 2 Aug 1996 20:44:55 +0800 (SST)
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Mathias Koerber <mathias at staff.singnet.com.sg>
X-Sender: mathias at singapura.singnet.com.sg
Reply-To: mathias at staff.singnet.com.sg
To: Robert Elz <hostmaster at munnari.oz.au>
cc: cidrd at iepg.org, iesg at ietf.org, ietf at ietf.org
Subject: Re: IESG review of draft-hubbard-registry-guidelines-03.txt
In-Reply-To: <7339.838987031 at munnari.OZ.AU>
Message-ID: <Pine.OSF.3.93.960802204138.27807G-100000 at singapura.singnet.com.sg>
X-Disclaimer: I don't speak for anyone except for myself (and to myself
Organization: SingNet
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 2 Aug 1996, Robert Elz wrote:
| Date: Fri, 02 Aug 1996 21:57:11 +1000
| From: Robert Elz <hostmaster at munnari.OZ.AU>
| To: mathias at staff.singnet.com.sg
| Cc: cidrd at iepg.org, iesg at ietf.org, ietf at ietf.org
| Subject: Re: IESG review of draft-hubbard-registry-guidelines-03.txt
|
| No. There is very much a question of how much the IETF should
| be working on what are basically policy areas - operations of the
| net, the registries, the DNS, the number space, etc. It seems
| there is little doubt but that the IETF is the best place to
| work on the technical matters related to all of these, it is by
| no means clear that the IETF is the best place to work on the
| politics (policies). That is a question that has been receiving
| some attention recently in several areas.
Exactly. In that sense a BCP document doumenting existing practices
does not mean that the registries are "bypassing" the IETF if they've done
what it describes before. Thus I agree with Dave Conrad that the BCP
documents what is current practice (levae aside whether even best or not),
but does make a standard. Or at least should not..
|
| If you want to establisg new standards w/o code, call them BRP
| (Best recommended practices), or just keep with STD..
|
| As I said, what they should be called is still very much an open
| question, with many opinions. For now, please forget the label,
| as it is quite possible that any doc now labelled BCP will
| eventually be relabelled with another acronym (or perhaps the
| same acronym derived from a different source).
|
| Please, everyone, whenever the question of "to BCP or not to BCP"
| arises, please consider this against what is written in the
| poised doc where the series is described, not by the label.
|
| Again I dsagree. Informational RFC need not even document current but
| only possible practices, techniques etc, to document them and maybe even
| explain why they were not chosen.. (by some, all, a few, whatever)..
|
| Sure - all of that provides information. There are lots of
| different kinds of information. Current practices are one kind
| of information that can be provided to the community.
|
| It's not impossible that "real good informational" may be something
| that's worth having - the poisson wg (follow on from poised'95)
| is going to discuss all of this - get involved in that effort.
|
| However, as currently defined that is not what BCP is.
Then maybe the document under discussion should not becomre BCP until we
agree more what BCP is or should be. Make it informational..
regards
|
| Read the docs.
|
| kre
|
Mathias Koerber | Tel: +65 / 471 9820 | mathias at staff.singnet.com.sg
SingNet NOC | Fax: +65 / 475 3273 | Mathias_Koerber at pobox.org.sg
Q'town Tel. Exch. | PGP: Keyid: 768/25E082BD, finger mathias at singnet.com.sg
2 Stirling Rd | 1A 8B FC D4 93 F1 9A FC BD 98 A3 1A 0E 73 01 65
S'pore 148943 | Disclaimer: I speak only for myself
* Eifersucht ist eine Leidenschaft, die mit Eifer sucht, was Leiden schafft *
Received: from ietf.org by ietf.org id aa12435; 2 Aug 96 9:15 EDT
Received: from cnri by ietf.org id aa12431; 2 Aug 96 9:15 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa06814; 2 Aug 96 9:15 EDT
Received: from ietf.org by ietf.org id aa12415; 2 Aug 96 9:14 EDT
Received: from ZAFU.BBN.COM by ietf.org id aa12401; 2 Aug 96 9:14 EDT
Received: from localhost (day at localhost) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id JAA11884; Fri, 2 Aug 1996 09:18:47 -0400 (EDT)
Message-Id: <199608021318.JAA11884 at zafu.bbn.com>
X-Authentication-Warning: zafu.bbn.com: Host day at localhost didn't use HELO protocol
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: John Day <day at bbn.com>
Subject: Re: IESG review of draft-hubbard-registry-guidelines-03.txt
To: bstewart at cisco.com
Cc: cidrd at iepg.org, hostmaster at munnari.oz.au, iesg at ietf.org, ietf at ietf.org,
mathias at staff.singnet.com.sg
In-Reply-To: <v03007801ae27a0eae444 at [171.69.128.42]>
Date: Fri, 2 Aug 96 09:14:59 EDT
Mail-System-Version: <BBN/MacEMail_v1.6 at BBN.COM>
>
>How long has it been since "RFC" really meant "Request for Comment?" Did
>it ever?
Yes, it did and it was used for that. There were some very good
discussions in the RFCs, circa 1970 - 1975.
Received: from ietf.org by ietf.org id aa12948; 2 Aug 96 9:29 EDT
Received: from cnri by ietf.org id aa12944; 2 Aug 96 9:29 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa07049; 2 Aug 96 9:29 EDT
Received: from ietf.org by ietf.org id aa12896; 2 Aug 96 9:29 EDT
Received: from apnic.hq.unu.edu by ietf.org id aa12881; 2 Aug 96 9:29 EDT
Received: by dragon.jp.apnic.net; id WAA09934; Fri, 2 Aug 1996 22:18:39 +0900
Received: from moonsky.jp.apnic.net(10.0.10.4) by dragon.jp.apnic.net via smap (g3.0.3)
id xma009930; Fri, 2 Aug 96 22:18:19 +0900
Received: from apnic.net (davidc at localhost) by moonsky.jp.apnic.net (8.7.1/8.7.1) with ESMTP id WAA13254; Fri, 2 Aug 1996 22:24:24 +0900 (JST)
Message-Id: <199608021324.WAA13254 at moonsky.jp.apnic.net>
X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs
To: Robert Elz <kre at munnari.oz.au>
cc: ietf at ietf.org, iesg at ietf.org
Subject: Re: IESG review of draft-hubbard-registry-guidelines-03.txt
In-reply-to: Your message of "Fri, 02 Aug 1996 20:00:19 +1000."
<7290.838980019 at munnari.OZ.AU>
Date: Fri, 02 Aug 1996 22:24:24 +0900
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: "David R. Conrad" <davidc at apnic.net>
Robert,
> It would appear there is some confusion, no doubt entirely on my part.
> I had thought the term "Best Current Practice" was to denote a
...
>Actually, I believe exactly the opposite. Forget the label, there
>is still much debate (and no consensus) as to what these things
>should be called.
Fine. Like I said, I was confused -- I thought "Best Current
Practice" stood for something like a "best" (as in, the goodest)
"current" (as in not before and not after) "practice" (like what
you do when you want to get good at something).
To be honest though, I frankly don't care in the slightest what
category the document falls under. People wanted a replacement for
1466 which is woefully out of date. The registries got together and
thrashed one out that documents what the registries do. It was
approved by the community in which the registries play a minor role.
We submitted it to the IESG for approval. IESG members then go off on
- how the current policies suck (yeah, I agree. Given the constraints
this isn't a big surprise)
- how wouldn't it be nice if we didn't have provider based addressing
(who cares if Internet isn't using it today)
- how the IESG would be made to be the fall guy if they approved the
document (even thought the IESG lawyer thought it was OK -- gotta
convince him he was wrong)
- how the registries are a monopoly (gosh, what a surprise)
- how a particular IESG member has it on good authority that one
DOMAIN NAME registry (and here I thought we were writing about
ADDRESS allocation policies) refused to provide information on
something that the people involved were not interested in releasing.
We tried to document what the registries do. We weren't trying to
create new policies -- it is NOT the registries place to do so. Some
members of the IESG feel they know what the problems are, so I
encourage them to submit a BCP (in *anybody's* definition) which the
registries will undoubtedly gleefully (seriously) take and implement.
> The document in question fairly accurately describes existing
> registry practices,
>That tells me two things. First, the registries have started doing
>this before any IETF standards blessing - ie: don't consider
>themselves bound by the IETF, and if the IETF community were to
>adopt a totally different approach would probably simply go on doing
>what they're doing.
No. The registries _implement_ policies. If the IETF or even its
associated bodies (e.g., IAB, IESG) were to come to a consensus on a
particular set of policies, the registries would implement those
policies. We have done so in the past (even though I for one thought
the policies were sub-optimal, see RFC 1814) and will do so in the
future.
>That raises the question as to whether this doc belongs as part of
>the IETF processes at all.
That it does. From the apparent inability for the IETF to even agree
upon a definition of "BCP", one might wonder if anything belongs in
the IETF.
Regards,
-drc
"Everything is wonderful, until you know something about it"
Received: from ietf.org by ietf.org id aa13964; 2 Aug 96 9:44 EDT
Received: from localhost by ietf.org id aa13164; 2 Aug 96 9:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: www-security at nsmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-wts-shttp-03.txt
Date: Fri, 02 Aug 1996 09:33:11 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608020933.aa13164 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Web Transaction Security
Working Group of the IETF.
Title : The Secure HyperText Transfer Protocol
Author(s) : E. Rescorla, A. Schiffman
Filename : draft-ietf-wts-shttp-03.txt
Pages : 46
Date : 08/01/1996
This memo describes a syntax for securing messages sent using the Hypertext
Transfer Protocol (HTTP), which forms the basis for the World Wide Web.
Secure HTTP (S-HTTP) provides independently applicable security services
for transaction confidentiality, authenticity/integrity and
non-repudiability of origin.
The protocol emphasizes maximum flexibility in choice of key
management mechanisms, security policies and cryptographic algorithms
by supporting option negotiation between parties for each transaction.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-wts-shttp-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-wts-shttp-03.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-wts-shttp-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960801112433.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-wts-shttp-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-wts-shttp-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960801112433.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13958; 2 Aug 96 9:44 EDT
Received: from localhost by ietf.org id aa13147; 2 Aug 96 9:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-ldapv3-dn-00.txt
Date: Fri, 02 Aug 1996 09:33:08 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608020933.aa13147 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of Distinguished Names
Author(s) : M. Wahl, S. Kille
Filename : draft-ietf-asid-ldapv3-dn-00.txt
Pages : 5
Date : 08/01/1996
The X.500 Directory uses distinguished names as the primary keys to entries
in the directory. Distinguished Names are encoded in ASN.1 in the X.500
Directory protocols. In the Lightweight Directory Access Protocol, a
string representation of distinguished names is transferred. This
specification defines the string format for representing names, which is
designed to give a clean representation of commonly used distinguished
names, while being able to represent any distinguished name.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-asid-ldapv3-dn-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3-dn-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-ldapv3-dn-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960801111346.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldapv3-dn-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldapv3-dn-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960801111346.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13963; 2 Aug 96 9:44 EDT
Received: from localhost by ietf.org id aa13182; 2 Aug 96 9:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: www-security at nsmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-wts-shtml-02.txt
Date: Fri, 02 Aug 1996 09:33:16 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608020933.aa13182 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Web Transaction Security
Working Group of the IETF.
Title : Security Extensions For HTML
Author(s) : E. Rescorla, A. Schiffman
Filename : draft-ietf-wts-shtml-02.txt
Pages : 3
Date : 08/01/1996
This memo describes a syntax for embedding S-HTTP negotiation parameters in
HTML documents. S-HTTP as described by draft-ietf-wts-shttp-03.txt contains
the concept of negotation headers which reflect the potential receiver of a
message's preferences as to which cryptographic enhancements should be
applied to the message. This document describes a syntax for binding these
negotiation parameters to HTML anchors.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-wts-shtml-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-wts-shtml-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-wts-shtml-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960801112725.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-wts-shtml-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-wts-shtml-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960801112725.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13953; 2 Aug 96 9:44 EDT
Received: from localhost by ietf.org id aa13072; 2 Aug 96 9:32 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-morgan-ident-ext-00.txt
Date: Fri, 02 Aug 1996 09:32:39 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608020932.aa13072 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : S/Ident: Security Extensions for the Ident Protocol
Author(s) : B. Morgan
Filename : draft-morgan-ident-ext-00.txt
Pages : 7
Date : 08/01/1996
The Ident protocol, RFC 1413, specifies a method for a host to request from
a remote host an assertion of an identifier associated with a TCP
connection between the two hosts. This memo proposes extensions to Ident
to support strong (i.e., cryptographic) authentication methods. The
extensions are based on the Simple Authentication and Security Layer
(SASL), draft-myers-auth-sasl-03.txt.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-morgan-ident-ext-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-morgan-ident-ext-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-morgan-ident-ext-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960801110855.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-morgan-ident-ext-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-morgan-ident-ext-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960801110855.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13959; 2 Aug 96 9:44 EDT
Received: from localhost by ietf.org id aa13128; 2 Aug 96 9:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-calhoun-vtp-protocol-00.txt
Date: Fri, 02 Aug 1996 09:33:01 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608020933.aa13128 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Virtual Tunneling Protocol (VTP)
Author(s) : P. Calhoun, E. Wong
Filename : draft-calhoun-vtp-protocol-00.txt
Pages : 62
Date : 08/02/1996
This document specifies a protocol which allows various Layer 2 and Layer 3
protocols to be tunneled through an IP network. VTP does not specify any
change to the protocol to be tunneled. It describes the mechanisms for
dynamically establishing and maintaining secure IP tunnels, and carrying
multiprotocol data over those tunnels. VTP can be used in the
implementation of Virtual Private Networks (VPNs).
A client-server architecture is defined in order to decouple functions
which exist in the tunnel initiation node and those in the tunnel
termination node. This protocol can be implemented in network devices such
as network access servers, routers and application servers. VTP
specifies a Mobile IP-like message exchange protocol to create and manage
IP tunnel sessions dynamically. VTP uses the GRE (Generic Routing
Encapsulation) mechanism to encapsulate multi-protocol payload traffic.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-calhoun-vtp-protocol-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-calhoun-vtp-protocol-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-calhoun-vtp-protocol-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960802093014.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-calhoun-vtp-protocol-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-calhoun-vtp-protocol-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960802093014.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13930; 2 Aug 96 9:44 EDT
Received: from localhost by ietf.org id aa13112; 2 Aug 96 9:32 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-ldap-domains-00.txt
Date: Fri, 02 Aug 1996 09:32:58 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608020932.aa13112 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : An Approach for Using Domains in
LDAP Distinguished Names
Author(s) : S. Kille, M. Wahl
Filename : draft-ietf-asid-ldap-domains-00.txt
Pages : 5
Date : 08/01/1996
The Lightweight Directory Access Protocol (LDAP) uses X.500-compatible
Distinguished Names for providing unique identifcation of entries.
Distinguished Names in currently-deployed X.500 directories have the
properties that they are descriptive, hierarchical, and follow common
organizational models. However, there is not today a universal
registration mechanism to permit individuals and organizations to obtain
Distinguished Names.
This document describes an experimental mechanism by which a name
registered with the Internet Domain Name Service, for which there is an
active registration service, can be represented as a Distinguished Name so
that it may be used with the LDAP protocol. This is not intended to have
LDAP replace the DNS protocol, but to permit further deployment of LDAP
into organizations connected to the Internet.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-asid-ldap-domains-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldap-domains-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-ldap-domains-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960801111942.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldap-domains-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldap-domains-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960801111942.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa14085; 2 Aug 96 9:44 EDT
Received: from ietf.org by ietf.org id aa13924; 2 Aug 96 9:44 EDT
Received: from localhost by ietf.org id aa13056; 2 Aug 96 9:32 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ediint at imc.org
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ediint-req-00.txt
Date: Fri, 02 Aug 1996 09:32:36 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608020932.aa13056 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Electronic Data
Interchange-Internet Integration Working Group of the IETF.
Title : Requirements for Inter-operable Internet EDI
Author(s) : C. Shih, M. Jansson, R. Drummond, L. Yarbrough
Filename : draft-ietf-ediint-req-00.txt
Pages : 29
Date : 08/01/1996
This memo is an informational document discussing the requirements for
inter-operable EDI, with sufficient background material to give an
explanation for the EDI community of the Internet-related issues.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ediint-req-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ediint-req-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ediint-req-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960801102833.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ediint-req-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ediint-req-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960801102833.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa14118; 2 Aug 96 9:44 EDT
Received: from ietf.org by ietf.org id aa13933; 2 Aug 96 9:44 EDT
Received: from localhost by ietf.org id aa13198; 2 Aug 96 9:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-rip at xylogics.com
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rip-ripng-applic-00.txt
Date: Fri, 02 Aug 1996 09:33:19 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608020933.aa13198 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Routing Information Protocol
Working Group of the IETF.
Title : RIPng Protocol Applicability Statement
Author(s) : G. Malkin
Filename : draft-ietf-rip-ripng-applic-00.txt
Pages : 4
Date : 08/01/1996
As required by Routing Protocol Criteria (RFC 1264), this report defines
the applicability of the RIPng protocol within the Internet. This report
is a prerequisite to advancing RIPng on the standards track.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rip-ripng-applic-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rip-ripng-applic-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rip-ripng-applic-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960801163746.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rip-ripng-applic-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rip-ripng-applic-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960801163746.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22421; 2 Aug 96 10:24 EDT
Received: from cnri by ietf.org id aa22417; 2 Aug 96 10:24 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa08064;
2 Aug 96 10:24 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <NAA29830 at pad-thai.cam.ov.com>; Fri, 2 Aug 1996 13:40:28 GMT
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA06663; Fri, 2 Aug 96 09:40:21 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <NAA29825 at pad-thai.cam.ov.com>; Fri, 2 Aug 1996 13:40:20 GMT
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id JAA18008; Fri, 2 Aug 1996 09:40:20 -0400
Message-Id: <199608021340.JAA18008 at winkl.cam.ov.com>
To: John Linn <linn at cam.ov.com>
Cc: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: CAT WG Review Last-Call: draft-myers-auth-sasl-04.txt
In-Reply-To: Your message of "Wed, 31 Jul 1996 13:00:28 EDT."
<199607311700.NAA17426 at winkl.cam.ov.com>
Date: Fri, 02 Aug 1996 09:40:19 -0400
Sender:ietf-archive-request at ietf.org
From: John Linn <linn at cam.ov.com>
[This is my response as an individual to the WG Review Last-Call which
I issued as chair.]
I'm concerned about some aspects of the SASL document, both procedural
and technical. Having reviewed draft-myers-sasl-04.txt, following
several technical revisions, my largest area of concern at this point
is procedural:
Section 5 of SASL proposes that an IANA-based facility be applied for
registration of SASL security mechanisms (to be used in parallel with
the base set of three SASL mechanisms defined in the draft: Kerberos
V4, GSS-API, and SKEY). I'm concerned about the following points:
(1) The section proposes that IANA act as a comment clearinghouse,
accepting comments on registered mechanisms, forwarding them to
mechanism owners, and making the comments generally accessible along
with the registrations. I'm not aware of precedent for IANA assuming
this role with other registered objects: is there precedent for IANA
taking on this responsibility, and/or has it been accepted by the IANA
for this case? In any event, I'd expect that an unmanaged stream of
comments posted in response to registered mechanisms could soon become
voluminous and difficult to interpret.
(2) The section suggests that authors of SASL mechanisms are
"encouraged to seek community review and comment whenever that is
feasible", by publishing as Internet-Drafts and optionally as
Informational RFCs. Nowhere in the section is the prospect of
specifying SASL mechanisms through the IETF standards track mentioned.
Given the fact that the SASL document defines three mechanisms
(including GSS-API which, in turn, enables access to a variety of
underlying security technologies), I'd expect that the need to define
additional SASL-level mechanisms should be fairly rare and that, if
such additional mechanisms were required for IETF purposes, their
definitions would appropriately target the same standards-track status
(and attendant community review) that SASL itself is targeting.
Specific content points:
Re section 5.2, 2nd paragraph, should the references here to "content
type" instead say "SASL mechanism"?
Re section 6, I think it would be useful, in a cross-mechanism fashion
or in conjunction with each mechanism's definition, to state what
behavior should occur if the proferred authorization identity is not
accepted by the server.
Re section 6.1, 2nd paragraph, 2nd sentence: are the Kerberos ticket
and authenticator included contiguously, in that order, and is any
other framing included within the message?
Re sec. 6.2.1, 3rd paragraph, and sec. 6.2.2, 2nd paragraph: both of these
paragraphs contain references to "protection mechanisms"; I believe that
they should be updated to "security layers" to match the term as used in
Sec. 6.2.3.
Sec. 6.3, 4th para, typo: "musth".
--jl
Received: from ietf.org by ietf.org id aa11340; 2 Aug 96 12:38 EDT
Received: from cnri by ietf.org id aa09526; 2 Aug 96 12:36 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa10186;
2 Aug 96 12:36 EDT
Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA21822>; Fri, 2 Aug 1996 09:35:45 -0700
Date: Fri, 2 Aug 1996 09:35:44 -0700
Sender:ietf-request at ietf.org
From: touch at isi.edu
Posted-Date: Fri, 2 Aug 1996 09:35:44 -0700
Message-Id: <199608021635.AA17121 at ash.isi.edu>
Received: by ash.isi.edu (5.65c/4.0.3-6)
id <AA17121>; Fri, 2 Aug 1996 09:35:44 -0700
To: ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms
Cc: touch at isi.edu, djb at koobera.math.uic.edu
X-Auto-Sig-Adder-By: faber at isi.edu
Source-Info: From (or Sender) name not authenticated.
> Date: 22 Jul 1996 08:13:39 -0000
> From: "D. J. Bernstein" <djb at koobera.math.uic.edu>
> To: ietf at CNRI.Reston.VA.US
> Subject: Re: Last Call: TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms
>
> > This sounds like the httpd hack I did a while back that rejects concurrent
> > connections from the same host, thus defeating Netscape's odd habit of opening
> > lots of simultaneous HTTP connections to the same place at the same time "to
> > get better service."
>
> Your hack ends up (1) increasing the per-user load on your host, (2)
> increasing the per-user load on the network, and (3) annoying the users.
> What exactly was the benefit supposed to be?
>
...
> Finally, if you're trying to optimize TCP's retransmit strategy across a
> bunch of connections rather than a single connection at once, go ahead
> and write some software. Multiple connections could in principle be
> treated as a single connection with a very large window. Yes, this will
> take work; did you really expect that a quick hack would solve anything?
>
> ---Dan
A recent Internet Draft may be of interest:
TCP Control Block Interdependence
Introduction
TCP is a connection-oriented reliable transport protocol layered over
IP [9]. Each TCP connection maintains state, usually in a data
structure called the TCP Control Block (TCB). The TCB contains
information about the connection state, its associated local process,
and feedback parameters about the connection's transmission
properties. As originally specified and usually implemented, the TCB
is maintained on a per-connection basis. This document discusses the
implications of that decision, and argues for an alternate
implementation that shares some of this state across similar
connection instances and among similar simultaneous connections. The
resulting implementation can have better transient performance,
especially for numerous short-lived and simultaneous connections, as
often used in the World-Wide Web [1]. These changes affect only the
TCB initialization, and so have no effect on the long-term behavior
of TCP after a connection has been established.
FYI.
Joe
----------------------------------------------------------------------
Joe Touch - touch at isi.edu http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/
USC / Research Assistant Prof. http://www.isi.edu/lsam/
Received: from ietf.org by ietf.org id aa13456; 2 Aug 96 12:50 EDT
Received: from ietf.org by ietf.org id aa13439; 2 Aug 96 12:50 EDT
Received: from lint.cisco.com by ietf.org id aa13347; 2 Aug 96 12:49 EDT
Received: from pferguso-pc.cisco.com (c1robo8.cisco.com [171.68.13.8]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id JAA05892; Fri, 2 Aug 1996 09:49:26 -0700
Message-Id: <199608021649.JAA05892 at lint.cisco.com>
X-Sender: pferguso at lint.cisco.com
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 02 Aug 1996 12:48:19 -0400
To: mathias at staff.singnet.com.sg
X-Orig-Sender:ietf-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Paul Ferguson <pferguso at cisco.com>
Subject: Re: IESG review of draft-hubbard-registry-guidelines-03.txt
Cc: Robert Elz <kre at munnari.oz.au>, "David R. Conrad" <davidc at apnic.net>,
cidrd at iepg.org, iesg at ietf.org, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 07:22 PM 8/2/96 +0800, Mathias Koerber wrote:
>
>If you claim that registries doing this already before the BCP are
>working outside the IETF, I think you are condemning the IETF process
>in total. There will always be grey ares where it is left up to
>individuals or groups to formulate policy in order to implement
>standards or make things work. The best of these should become
>BCP *after* they have proven successful..
>
I don't seem to recall the registries being bound to operate within
the confines of the IETF, so BCP really has no functional impact,
other than the IETF has blessed it. Makes no difference in operational
regards.
- paul
Received: from ietf.org by ietf.org id aa15888; 2 Aug 96 13:59 EDT
Received: from anduin.ocf.llnl.gov by ietf.org id aa15801; 2 Aug 96 13:57 EDT
Received: from [128.115.96.72] (macyoungs.llnl.gov) by anduin.ocf.llnl.gov (4.1/SMI-4.0)
id AA26641; Fri, 2 Aug 96 10:57:52 PDT
X-Sender: jed at anduin.ocf.llnl.gov
Message-Id: <v01540b03ae27fbae4b3c at [128.115.96.72]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 2 Aug 1996 10:58:51 -0800
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: "James E. [Jed] Donnelley" <jed at llnl.gov>
Subject: Re: Scientific Discoveries - how to deal with Spam
Source-Info: From (or Sender) name not authenticated.
This latest Spam instance hit me just after reviewing an
old note from Dave Crocker on this topic:
>Date: Tue, 6 Feb 1996 11:54:11 -0800
>From: Dave Crocker <dcrocker at brandenburg.com>
>Subject: Re: Protection against spammers
>
>At 7:14 AM 2/6/96, Christian Huitema wrote:
>>management maintains a list of "usual" senders and were a moderator screens
>>the message originating from "unusual" senders - updating the list if
>>required.
>
> I had forgotten about the "background moderator" mode of operation,
>in which typical messages flow automatically and the so-called moderator is
>used only for messages from unusual senders. I agree with you that this
>mode would likely be quite a reasonable style of operation, assuming the
>moderator has an easy time of adding and deleting accepted addresses.
>
>d/
I would be concerned that doing any sort of moderation as above
would cost too much human time (though I don't know how it compares
with the cost of supporting the list as it is). However the
above note got me to thinking about alternatives.
What about limiting senders to the list to receivers of the
list? I would be surprised if health at moneyworld.com is
a regular receiver of the IETF mailings. Might not this
be an approach to pretty much eliminate Spam with no
substantial additional cost in list support (assuming such
an option is available).
One negative would be that we would not longer be able to receive
notes from "anyone" that do relate to legitimate IETF issues.
I personally believe it wouldn't be so bad to require anyone
not on the list with such an issue to essentially be sponsored
by someone on the list - or to be added to the list for
the time they are interested in a particular topic.
I am not an e-mail expert, and I apologize if I am just adding
another wasted message for folks to throw away. Still, it strikes
me that a little effort in one area (list management) might
save us all a considerable cumulative amount of bother if
something simple like the above would do the trick (though I
have to admit that I spend more time thinking about the general
issue than I do throwing away the Spam - a computerese afliction?).
So, two questions: 1. is it technically possible?, and
2. Is it a good idea?
I suggest responding directly to me (only) to avoid futher bothering
everyone on the list. I would particularly like to hear from
whoever is responsible for supporting the list (without whom
nothing will be possible even if it is a good idea). I will
summarize (or get help doing so) and see that a report is made
to the list if appropriate.
P.S. One thing I noticed about the "Aging" Spam is that it was sent
to "ietf at isi.edu" and not "ietf at ietf.org". If anyone knows the
significance of this (e.g. limiting authors as above to
ieft at ietf.org wouldn't help the problem - some old ISI list
would also have to be canned) I would like to hear about it.
--Jed http://www-atp.llnl.gov/atp/jed-signature.html
Received: from ietf.org by ietf.org id aa17043; 2 Aug 96 14:13 EDT
Received: from cnri by ietf.org id aa17039; 2 Aug 96 14:13 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11799;
2 Aug 96 14:13 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <RAA11097 at pad-thai.cam.ov.com>; Fri, 2 Aug 1996 17:32:17 GMT
Received: from PO10.ANDREW.CMU.EDU by MIT.EDU with SMTP
id AA01296; Fri, 2 Aug 96 13:32:12 EDT
Received: (from postman at localhost) by po10.andrew.cmu.edu (8.7.5/8.7.3) id NAA00721 for cat-ietf at mit.edu; Fri, 2 Aug 1996 13:32:03 -0400
Received: via switchmail; Fri, 2 Aug 1996 13:32:02 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.Qm0XgXW00WBw00ubU0>;
Fri, 2 Aug 1996 13:30:11 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr7/jgm/.Outgoing/QF.sm0XgWC00WBw0Yk:A0>;
Fri, 2 Aug 1996 13:30:10 -0400 (EDT)
Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.54
via MS.5.6.hogtown.andrew.cmu.edu.sun4_51;
Fri, 2 Aug 1996 13:30:08 -0400 (EDT)
Message-Id: <Am0XgUi00WBw0Yk_00 at andrew.cmu.edu>
Date: Fri, 2 Aug 1996 13:30:08 -0400 (EDT)
Sender:ietf-archive-request at ietf.org
From: John Gardiner Myers <jgm at cmu.edu>
To: cat-ietf at mit.edu
Subject: Re: CAT WG Review Last-Call: draft-myers-auth-sasl-04.txt
In-Reply-To: <199608021340.JAA18008 at winkl.cam.ov.com>
References: <199608021340.JAA18008 at winkl.cam.ov.com>
John Linn <linn at cam.ov.com> writes:
> (1) The section proposes that IANA act as a comment clearinghouse,
> [...]. I'm not aware of precedent for IANA assuming
> this role with other registered objects: is there precedent for IANA
> taking on this responsibility, and/or has it been accepted by the IANA
> for this case?
This text was lifted from draft-ietf-822ext-mime-reg-04.txt, which I
believe is currently in IETF-wide Last Call.
> (2) The section suggests that authors of SASL mechanisms are
> "encouraged to seek community review and comment whenever that is
> feasible", by publishing as Internet-Drafts and optionally as
> Informational RFCs. Nowhere in the section is the prospect of
> specifying SASL mechanisms through the IETF standards track mentioned.
I personally don't see the need to belabor the obvious, though I'm
certainly open to suggestios for clarifying wording. I don't see the
need for the namespace complexity of
draft-ietf-822ext-mime-reg-04.txt. There are going to be far fewer
SASL mechanisms than media types.
The situation is akin to assigning well known ports to protocols.
There needs to be a registry mapping names (ports) to mechanisms
(protocols). The need to register the name/port is independent of the
need/desire to standardize the protocol. We encourage, but do not
require the specifics of the protocol to be disclosed. If, after
publishing an internet-draft as suggested by the registration
document, there is community interest, then the rest of the IETF
standards track process can continue.
> Given the fact that the SASL document defines three mechanisms
> (including GSS-API which, in turn, enables access to a variety of
> underlying security technologies), I'd expect that the need to define
> additional SASL-level mechanisms should be fairly rare and that, if
> such additional mechanisms were required for IETF purposes, their
> definitions would appropriately target the same standards-track status
> (and attendant community review) that SASL itself is targeting.
There is currently a mechanism named CHAP in IETF-wide Last Call.
There is also an unpublished anonymous-diffie-hellman mechanism that
has been developed by an SMTP server vendor. (I am currently trying
to get the author of same to publish the spec as an I-D).
Frankly, I have no idea if the creation/registration of new SASL
mechanisms will be frequent or rare. I suppose a large part of it
will depend on whether or not GSSAPI is accepted.
> Re section 5.2, 2nd paragraph, should the references here to "content
> type" instead say "SASL mechanism"?
Yes, fixed.
> Re section 6, I think it would be useful, in a cross-mechanism fashion
> or in conjunction with each mechanism's definition, to state what
> behavior should occur if the proferred authorization identity is not
> accepted by the server.
Each mechanism states that the server must "verify" such-and-such.
The authorization of the identity in the credentials to authenticate
as the proferred authorization identity is but one thing each
mechanism requires be verified.
It is a rather fundamental concept that if any verification fails, the
exchange fails and the server indicates this through the method
defined in the protocol's profile. Perhaps I should state this in
section 3?
> Re section 6.1, 2nd paragraph, 2nd sentence: are the Kerberos ticket
> and authenticator included contiguously, in that order, and is any
> other framing included within the message?
They are included contiguously, as krb_mk_req() in the MIT API
generates them. This is fairly standard in Kerberos v4-based schemes.
> Re sec. 6.2.1, 3rd paragraph, and sec. 6.2.2, 2nd paragraph: both of these
> paragraphs contain references to "protection mechanisms"; I believe that
> they should be updated to "security layers" to match the term as used in
> Sec. 6.2.3.
fixed
> Sec. 6.3, 4th para, typo: "musth".
Was fixed based on someone else's comment.
--
_.John Gardiner MyersInternet: jgm+ at CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
Received: from ietf.org by ietf.org id aa20506; 2 Aug 96 16:23 EDT
Received: from cnri by ietf.org id aa20502; 2 Aug 96 16:23 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13869;
2 Aug 96 16:23 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <TAA17835 at pad-thai.cam.ov.com>; Fri, 2 Aug 1996 19:45:25 GMT
Received: from Level.Stanford.EDU by MIT.EDU with SMTP
id AA15140; Fri, 2 Aug 96 15:45:23 EDT
Received: by level.Stanford.EDU; id AA07295; Fri, 2 Aug 1996 12:45:22 -0700
Date: Fri, 2 Aug 96 12:44:58 -0700
Sender:ietf-archive-request at ietf.org
From: RL Bob Morgan <Bob.Morgan at stanford.edu>
To: cat-ietf at mit.edu
Subject: Ident and SASL
Message-Id: <Mailstrom.1.06.43210.3853.morgan at networking.stanford.edu>
Content-Type: TEXT/plain; charset=US-ASCII
The CAT group may be interested in the newly-posted I-D described below.
Stanford is working on implementations for various platforms, primarily to
support use of our kerb4 infrastructure with WWW servers.
It may be that CAT is an appropriate WG to host standards-track advancement of
this proposal, if such advancement is warranted. Firing up a new Ident WG would
be more painful.
Regarding the current last-call for SASL, I'm hopeful that this brand-new use of
it will help to illustrate its utility rather than muddying the discussion. Let
me note that this proposal was developed completely independently of SASL
itself.
- RL "Bob" Morgan
Stanford
---
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : S/Ident: Security Extensions for the Ident Protocol
Author(s) : B. Morgan
Filename : draft-morgan-ident-ext-00.txt
Pages : 7
Date : 08/01/1996
The Ident protocol, RFC 1413, specifies a method for a host to request from
a remote host an assertion of an identifier associated with a TCP
connection between the two hosts. This memo proposes extensions to Ident
to support strong (i.e., cryptographic) authentication methods. The
extensions are based on the Simple Authentication and Security Layer
(SASL), draft-myers-auth-sasl-03.txt.
Received: from ietf.org by ietf.org id aa21439; 2 Aug 96 17:04 EDT
Received: from cnri by ietf.org id aa21435; 2 Aug 96 17:04 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14518;
2 Aug 96 17:04 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <UAA20449 at pad-thai.cam.ov.com>; Fri, 2 Aug 1996 20:34:09 GMT
Received: from dns.sprintcorp.com by MIT.EDU with SMTP
id AA20107; Fri, 2 Aug 96 16:34:08 EDT
Received: from firewall by dns.sprintcorp.com (5.4R3.10/200.2.1.5)
id AA22648; Fri, 2 Aug 1996 15:36:22 -0500
X-Orig-Sender: ashraf at dns.sprintcorp.com
Message-Id: <3202662B.2FE7 at sprintcorp.com>
Date: Fri, 02 Aug 1996 15:33:47 -0500
Sender:ietf-archive-request at ietf.org
From: "Ashraf Madoukh - (913)534.3137" <ashraf at dns.sprintcorp.com>
Organization: Sprint
X-Mailer: Mozilla 2.02 (X11; I; SunOS 5.5 sun4u)
Mime-Version: 1.0
To: cat-ietf at mit.edu
Subject: GSS-API C-Binding
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'm working on building security services for distributed objects in ATM
networks. I was reading in GSS-API C-Binding July 1995 and I have some
questions:
1. What is the latest draft for GSS-API C-Binding?
2. How can I get the latest one?
3. Gssapi.h has the following statements:
/*
* First, define the three platform-dependent pointer types.
*/
typedef <platform-specific> gss_ctx_id_t;
typedef <platform-specific> gss_cred_id_t;
typedef <platform-specific> gss_name_t;
/*
* The following type must be defined as the smallest natural
* unsigned integer supported by the platform that has at least
* 32 bits of precision.
*/
typedef <platform-specific> gss_uint32;
What do you mean by <platform-specific> and how I can define it.
I'm trying to build this for both Sun Solaris and Windows NT.
I look forward to hearing from you.
Regards,
Ashraf Madoukh
Received: from ietf.org by ietf.org id aa22972; 2 Aug 96 18:09 EDT
Received: from cnri by ietf.org id aa22868; 2 Aug 96 18:04 EDT
Received: from poblano.near.net by CNRI.Reston.VA.US id aa15443;
2 Aug 96 18:04 EDT
Received: from jcurran.bbnplanet.com by poblano.bbnplanet.com id aa27053;
2 Aug 96 18:03 EDT
X-Sender: jcurran at 198.114.157.116
Message-Id: <v02140b0eae282716a6af at [206.231.68.12]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Phone: (617) 873-4398
USMail: 150 CambridgePark Drive, Cambridge, MA, 02140
Date: Fri, 2 Aug 1996 18:03:36 -0400
To: Mark Crispin <mrc at panda.com>
Sender:ietf-request at ietf.org
From: John Curran <jcurran at bbnplanet.com>
Subject: Re: spam message from health at moneyworld.com
Cc: Internet Engineering Task Force <ietf at CNRI.Reston.VA.US>,
spam at zorch.sf-bay.org
Source-Info: From (or Sender) name not authenticated.
At 0:37 8/2/96, Mark Crispin wrote:
>Moneyworld.com just attacked the IETF mailing list with an advertisement
>for vitamins. This domain is owned by one William C. Newell d/b/a/
>Financial Connections Inc., 2508 5th Ave Suite 104, Seattle, WA 98121.
>This is not the William C. Newell listed in the Seattle phone book.
>
>It is useless to complain to moneyworld.com's administrators, since those
>administrators themselves are the problem. ISP service is provided by MCI
>(which has promised to terminate their service) and by BBN Planet (which
>has not yet responded to complaints).
Mark,
We don't terminate without process. We've been working on this
site (which is the customer of a BBN Planet business partner) since
early July, but folks are going to have to be patient for another few
weeks due to notice requirements. I thought that an update had gone
out to folks on the ticket but will confirm, as we shouldn't have to
exchange email via the ietf list to keep folks up to date.
As a policy, we do terminate sites who spam mailing lists to the
detriment of other customers, but we refuse to act without
proper notice and process (since the alternative creates a great
denial-of-service attack... ;-)
/John
Received: from ietf.org by ietf.org id aa11977; 3 Aug 96 8:04 EDT
Received: from cnri by ietf.org id aa11973; 3 Aug 96 8:04 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa05382; 3 Aug 96 8:04 EDT
Received: from ietf.org by ietf.org id aa11965; 3 Aug 96 8:04 EDT
Received: from apnic.hq.unu.edu by ietf.org id aa11952; 3 Aug 96 8:04 EDT
Received: by dragon.jp.apnic.net; id UAA16990; Sat, 3 Aug 1996 20:53:40 +0900
Received: from moonsky.jp.apnic.net(10.0.10.4) by dragon.jp.apnic.net via smap (g3.0.3)
id xma016982; Sat, 3 Aug 96 20:53:10 +0900
Received: from apnic.net (davidc at localhost) by moonsky.jp.apnic.net (8.7.1/8.7.1) with ESMTP id UAA18601; Sat, 3 Aug 1996 20:59:17 +0900 (JST)
Message-Id: <199608031159.UAA18601 at moonsky.jp.apnic.net>
X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs
To: Sean Doran <smd at cesium.clock.org>
cc: "David R. Conrad" <davidc at apnic.net>, sob at newdev.harvard.edu,
iesg at ietf.org, ietf at ietf.org
Subject: Re: IESG review of draft-hubbard-registry-guidelines-03.txt
In-reply-to: Your message of "Sat, 03 Aug 1996 01:34:56 PST."
<96Aug3.013457pdt.119175-28859+5 at cesium.clock.org>
Date: Sat, 03 Aug 1996 20:59:17 +0900
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: "David R. Conrad" <davidc at apnic.net>
Sean:
>would you go so far as to agree with me in saying it has
>become reasonable to believe that the IESG has indicated
>that they are not competent to produce or endorse policies
>on these sorts of things at all
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
