[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
Given Internet Is Doubling Each Year:
1/2 of all Internet denizens have been here less than 1 year;-)...
3/4 less than 2 years...
7/8 less than 3 years...
15/16 less than 4 years...
31/32 less than 5 years...
Somehow I fail to see any reason to continue my analysis;-)...
What does it mean to have been around here for 21 years? Or more?
}
}> I believe that we need a blue-ribbon panel--consisting mainly
}> or entirely of people who contributed to notable ietf successes
}> over the years and who still hold to the original principles
}> behind those successes--to come up with concrete recommendations
}> for re-establishing focus.
}
}I can't say I'm a strong believer in blue-ribbon panels. However, there is
}an installed panel, the IESG, to which I will forward your recommendations.
}
A salient feature of the Internet since it began is that it draws
energy and focus from its chaos, and actually seems to find ways to
add chaos when things become too orderly. That is what the Boston Tea
Party and establishment of POSIED was all about. Too much order had
accumulated in the form of crust and it had to be broken up to achieve
the desired level of chaos, else it was going to fail.
}
}I think it only fair to point out, however, that the issue in IPSEC wasn't
}necessarily in the charter, but in the politics within the working group.
}Working groups which set themselves to achieve an objective by a given
}approach have a pretty strong track record of achieving it. IPSEC has had a
}number of proposals, and the discussion between them has involved a fair
}amount of discord. Individuals in the working group have simply refused to
}yield ground, which is not a recipe for consensus.
}
This to me is a sign of too much order getting in the way of open
thinking, so how about a mini-tea party where we throw it all
overboard and try something new? I recall something like this
happening in the PEM WG too, and perhaps in some others where
orderliness somehow became the enemy instead of a tool. The problem
in these cases is to get outside the orderly boxed thinking that is
blocking the required creative processes. SNMPv2 got caught in this
same box, as I read the tea leaves.
}
}You might be interested to know that one member of the working group has
}sent me a detailed informal complaint, which I am researching.
}
}> One step I think should be considered
}> is for wg charters to *detail* the list of requirements to be
}> satisfied by the wg...with any material changes to that set
}> entailing iesg approval and re-issuance of the charter. Things
}> like that. It's pretty clear that we are not going to see the
}> original collective understanding--pragmatic solutions to well-
}> defined problems within a reasonably narrow scope--re-materialize
}> under the present circumstances.
}
This sounds like a nice formula for an orderly tea party;-)...
}
}That depends on people. I am certainly willing to use the charter process
}to manage working groups, but the issue is the willingness of people to
}focus and execute, not in the legal contexts that might deny them the right
}to be unfocussed.
}
Hmmm, I think the missing idea is that you need to get the tea wet to
consider the reset/restart party a success. The idea as I see it is
to force the WG to accept that it needs to rething its charter if it
does not met its established goals, and this forces the process to
open up and reconsider other options and new ways of looking at
things. In short, it adds a dash of chaos and moves the process
further away from the boundary of order, but still within the realm of
bounded chaos.
Forcing a process back through open rechartering cannot be the end of
the earth, or the end of the Internet, or the end of the IETF, or the
end of the effort to find a solution.
But the rechartering process has to be truly open!
Some view this as accepting that you cannot get what you want
(whatever that might be) until you openly admit that you are willing
to give it up.
Bottom line is -- We need to add some bounded chaos whenever the IETF
becomes too orderly;-)... It simply cannot evolve with too much
order.
Cheers...\Stef
Received: from ietf.org by ietf.org id aa11029; 17 Sep 96 9:27 EDT
Received: from localhost by ietf.org id aa10786; 17 Sep 96 9:22 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: idmr at cs.ucl.ac.uk
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-idmr-pim-dm-spec-04.txt, .ps
Date: Tue, 17 Sep 1996 09:22:24 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609170922.aa10786 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 Inter-Domain Multicast
Routing Working Group of the IETF.
Title : Protocol Independent Multicast-Dense Mode (PIM-DM):
Protocol Specification
Author(s) : D. Estrin, D. Farinacci, A. Helmy,
V. Jacobson, L. Wei
Filename : draft-ietf-idmr-pim-dm-spec-04.txt, .ps
Pages : 13
Date : 09/16/1996
This specification defines a multicast routing algorithm for multicast
groups that are densely distributed across an internet. The protocol is
unicast routing protocol independent. It is based on the PIM sparse-mode
[Deering95] and employs the same packet formats. This protocol is called
dense-mode PIM. The design is based largely on foundational work by Deering
[Deering91].
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-idmr-pim-dm-spec-04.txt".
Or
"get draft-ietf-idmr-pim-dm-spec-04.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-pim-dm-spec-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-idmr-pim-dm-spec-04.txt".
Or
"FILE /internet-drafts/draft-ietf-idmr-pim-dm-spec-04.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: <19960916135929.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-idmr-pim-dm-spec-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idmr-pim-dm-spec-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960916135929.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11232; 17 Sep 96 9:28 EDT
Received: from localhost by ietf.org id aa10784; 17 Sep 96 9:22 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: idmr at cs.ucl.ac.uk
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-idmr-pim-sm-spec-06.txt, .ps
Date: Tue, 17 Sep 1996 09:22:21 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609170922.aa10784 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 Inter-Domain Multicast
Routing Working Group of the IETF.
Title : Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification
Author(s) : D. Estrin, D. Farinacci, A. Helmy, D. Thaler,
S. Deering, M. Handley, V. Jacobson, C. Liu,
P. Sharma, L. Wei
Filename : draft-ietf-idmr-pim-sm-spec-06.txt, .ps
Pages : 77
Date : 09/16/1996
This document describes a protocol for efficiently routing to multicast
groups that may span wide-area (and inter-domain) internets. We refer to
the approach as Protocol Independent Multicast--Sparse Mode (PIM-SM)
because it is not dependent on any particular unicast routing protocol, and
because it is designed to support sparse groups as defined in [1][2].
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-idmr-pim-sm-spec-06.txt".
Or
"get draft-ietf-idmr-pim-sm-spec-06.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-pim-sm-spec-06.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-idmr-pim-sm-spec-06.txt".
Or
"FILE /internet-drafts/draft-ietf-idmr-pim-sm-spec-06.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: <19960916135103.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-idmr-pim-sm-spec-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idmr-pim-sm-spec-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960916135103.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11230; 17 Sep 96 9:28 EDT
Received: from localhost by ietf.org id aa10725; 17 Sep 96 9:21 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-mixer at innosoft.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-mixer-images-01.txt
Date: Tue, 17 Sep 1996 09:21:46 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609170921.aa10725 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 - X.400 Gateway Working
Group of the IETF.
Title : X.400 image body parts
Author(s) : H. Alvestrand
Filename : draft-ietf-mixer-images-01.txt
Pages : 4
Date : 09/16/1996
This document contains the body parts defined in RFC 1495 for carrying
image formats that were originally defined in MIME through an X.400 system.
This document is an Experimental standard; if it turns out to be useful and
widely deployed, it can be moved onto the standards track.
It also documents the OIDs assigned to these data formats as FTAM
body parts, which allow the MIME types to be converted to FTAM body parts;
this will probably be more useful than the new body parts defined here.
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-mixer-images-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mixer-images-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-mixer-images-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: <19960916104756.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mixer-images-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mixer-images-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960916104756.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11240; 17 Sep 96 9:28 EDT
Received: from localhost by ietf.org id aa10707; 17 Sep 96 9:21 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
cc: mobile-ip at smallworks.com, ipsec at tis.com
Subject: I-D ACTION:draft-montenegro-firewall-sup-00.txt
Date: Tue, 17 Sep 1996 09:21:38 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609170921.aa10707 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Firewall Support for Mobile IP
Author(s) : G. Montenegro, V. Gupta
Filename : draft-montenegro-firewall-sup-00.txt
Pages : 22
Date : 09/16/1996
The Mobile IP specification establishes the mechanisms that enable a mobile
host to maintain and use the same IP address as it changes its point of
attachment to the network. Mobility implies higher security risks than
static operation, because the traffic may at times take unforeseen network
paths with unknown or unpredictable security characteristics. The Mobile IP
specification uses cryptographic techniques to authenticate the parties
involved in the registration protocol. However, it makes no provisions for
securing data traffic. The mechanisms described in this document allow a
mobile node out on a public sector of the network to negotiate ccess past a
SKIP firewall, and construct a secure channel into its home network.
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-montenegro-firewall-sup-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-montenegro-firewall-sup-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-montenegro-firewall-sup-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: <19960916100728.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-montenegro-firewall-sup-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-montenegro-firewall-sup-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960916100728.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11236; 17 Sep 96 9:28 EDT
Received: from localhost by ietf.org id aa10751; 17 Sep 96 9:22 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipsec at tis.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-ipsec-esp-des-md5-03.txt
Date: Tue, 17 Sep 1996 09:22:05 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609170922.aa10751 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 IP Security Protocol Working
Group of the IETF.
Title : Combined DES-CBC, HMAC and Replay Prevention Security
Transform
Author(s) : J. Hughes
Filename : draft-ietf-ipsec-esp-des-md5-03.txt
Pages : 14
Date : 09/16/1996
This draft describes a combination of privacy, authentication, integrity
and replay prevention into a single packet format.
This document is the result of significant work by several major
contributors and the IPsec working group as a whole. These contributors,
cited later in this document, provided many of the key technical details
summarized in this document. [IB93] [IBK93]
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-ipsec-esp-des-md5-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-des-md5-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-ipsec-esp-des-md5-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: <19960917091751.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-esp-des-md5-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-esp-des-md5-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960917091751.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11238; 17 Sep 96 9:28 EDT
Received: from localhost by ietf.org id aa10823; 17 Sep 96 9:22 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: fddi-mib at cs.utk.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-fddimib-objects-v2-02.txt
Date: Tue, 17 Sep 1996 09:22:33 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609170922.aa10823 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 FDDI MIB Working Group of
the IETF.
Title : FDDI Management Information Base
Author(s) : J. Case, A. Rijsinghani
Filename : draft-ietf-fddimib-objects-v2-02.txt
Pages : 63
Date : 09/16/1996
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it defines objects for managing devices which implement the
FDDI based on the ANSI FDDI SMT Standard X3.229-1994 [8]. Note that the
technical content of that standard is identical to that of the ANSI SMT
version 7.3 draft standard.
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-fddimib-objects-v2-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-fddimib-objects-v2-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-fddimib-objects-v2-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: <19960916171406.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-fddimib-objects-v2-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-fddimib-objects-v2-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960916171406.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11613; 17 Sep 96 9:32 EDT
Received: from localhost by ietf.org id aa10768; 17 Sep 96 9:22 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-doolan-tdp-spec-00.txt
Date: Tue, 17 Sep 1996 09:22:14 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609170922.aa10768 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Tag Distribution Protocol
Author(s) : P. Doolan, B. Davie, D. Katz,
Y. Rekhter, E. Rosen
Filename : draft-doolan-tdp-spec-00.txt
Pages : 30
Date : 09/16/1996
An overview of a tag switching architecture is provided in [Rekhter].
This document defines the Tag Distribution Protocol (TDP) referred to in
[Rekhter].
TDP is a two party protocol that runs over a connection oriented transport
layer with guaranteed sequential delivery. Tag Switching Routers use TDP
to communicate tag binding information to their peers. TDP supports
multiple network layer protocols including but not limited to IPv4, IPv6,
IPX and AppleTalk.
We define here the PDUs and operational procedures for this TDP and
specify its transport requirements.
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-doolan-tdp-spec-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-doolan-tdp-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-doolan-tdp-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: <19960916132337.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-doolan-tdp-spec-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-doolan-tdp-spec-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960916132337.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ab11613; 17 Sep 96 9:32 EDT
Received: from localhost by ietf.org id aa10810; 17 Sep 96 9:22 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-dusse-mime-msg-spec-00.txt
Date: Tue, 17 Sep 1996 09:22:29 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609170922.aa10810 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : S/MIME Message Specification: PKCS Security
Services for MIME
Author(s) : S. Dusse
Filename : draft-dusse-mime-msg-spec-00.txt
Pages : 11
Date : 09/16/1996
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a standard
way to send and receive secure electronic mail. Based on the popular
Internet MIME standard (RFC 1521), S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and privacy and data security (using encryption).
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-dusse-mime-msg-spec-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-dusse-mime-msg-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-dusse-mime-msg-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: <19960916170120.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-dusse-mime-msg-spec-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-dusse-mime-msg-spec-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960916170120.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ac11613; 17 Sep 96 9:33 EDT
Received: from localhost by ietf.org id aa10842; 17 Sep 96 9:22 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: fddi-mib at cs.utk.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-fddimib-smiv2-object-v2-01.txt
Date: Tue, 17 Sep 1996 09:22:36 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609170922.aa10842 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 FDDI MIB Working Group of
the IETF.
Title : FDDI Management Information Base in the SNMPv2 SMI
Author(s) : J. Case, A. Rijsinghani
Filename : draft-ietf-fddimib-smiv2-object-v2-01.txt
Pages : 66
Date : 09/16/1996
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it defines objects for managing devices which implement the
FDDI based on the ANSI FDDI SMT Standard X3.229-1994 [8]. Note that the
technical content of that standard is identical to that of the ANSI SMT
version 7.3 draft standard.
The MIB module contained in this memo is updated to be defined using
the SNMPv2 SMI [9], but is otherwise identical to that contained in [11].
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-fddimib-smiv2-object-v2-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-fddimib-smiv2-object-v2-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-fddimib-smiv2-object-v2-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: <19960916171812.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-fddimib-smiv2-object-v2-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-fddimib-smiv2-object-v2-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960916171812.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29202; 17 Sep 96 15:17 EDT
Received: from f-umbc7.umbc.edu by ietf.org id aa29013; 17 Sep 96 15:11 EDT
Received: (from sidhu at localhost) by umbc7.umbc.edu (8.6.12/Umbc) id PAA15777; Tue, 17 Sep 1996 15:11:14 -0400
Date: Tue, 17 Sep 1996 15:11:14 -0400
Sender:ietf-request at ietf.org
From: "Dr. Deepinder Sidhu (CMSC)" <sidhu at umbc.edu>
Message-Id: <199609171911.PAA15777 at umbc7.umbc.edu>
To: ietf at ietf.org
Subject: 7th maryland Workshop on Very High Speed Networks
Cc: sidhu at umbc7.umbc.edu, mctr at cs.umbc.edu
Source-Info: From (or Sender) name not authenticated.
----------------------------------------------------
7th Maryland Workshop on Very High Speed Networks
----------------------------------------------------
November 5-6, 1996
Maryland Center for Telecommunications Research
Department of Computer Science and Electrical Engineering
University of Maryland Baltimore County
The Maryland Center for Telecommunications Research (MCTR) and
Department of Computer Science and Electrical Engineering at the
University of Maryland Baltimore County (UMBC) will hold the
7th Maryland Workshop on Very High Speed Networks on November 5-6,
1996 at the UMBC campus. The Workshop will be held in the Ballroom
of the University Center on the UMBC campus.
The goal of the Workshop is to bring together experts in related
areas to discuss progress and research issues in the design and
implementation of very high speed communication networks. Each of
the previous workshops attracted approximately 150 researchers
representing academia, industry and government. The two day
meeting will include invited speakers and contributed presentations.
Papers on selected presentations will appear in a special issue of
the Journal of High Speed Networks.
For more information on the workshop and directions to UMBC,
check our home page on WWW.(http://www.mctr.umbc.edu)
A registration fee of $325 will include two lunches and conference
proceeding. For questions regarding the technical content of the
workshop or giving a presentation, please contact the workshop
organizer, Dr. Deepinder Sidhu, at
Tel: (410) 455-3028 or 3063, Fax: (410) 455-3969,
Email: mctr at cs.umbc.edu.
Mail checks (payable to University of Maryland Foundation) and
registration form to Dr. D. P. Sidhu, Maryland Center for
Telecommunications Research, University of Maryland Baltimore County,
1000 Hilltop Circle, Baltimore, MD 21250. All funds for this event will
be managed by the UM foundation.
Please DO NOT include hotel accommodation expenses in your payment
for the Workshop Registration. Room payment should be made directly
to the hotel you selected for stay. The following hotels are closest
to UMBC campus. Some hotels may offer reduced rate. To obtain the reduced
rate, you must identify yourself as an attendee of this workshop.
BWI Airport is approximately five miles from UMBC Campus.
1. Sheraton International Hotel - BWI Airport. Closest to airport
and UMBC campus. Tel: (410) 859-3300 or (800) 638-5858
2. Holiday Inn - BWI Airport. Close to airport and UMBC campus.
Tel: (410) 859-8400 or (800) HOLIDAY
3. Omni Inner Harbor Hotel. Close to Downtown Baltimore / Inner
Harbor. About 20 minutes drive to UMBC campus.
Tel: (410) 752-1100 or (800) 843-6664
For more information on the workshop and directions to UMBC,
check our home page on WWW.(http://www.mctr.umbc.edu)
-------------------------------------------------------------------------------
7th Maryland Workshop on Very High Speed Networks
(November 5-6, 1996)
Registration Form
Name:
----------------------------------------------------------------------
Affiliation:
-------------------------------------------------------------
Address: -------------------------------------------------------------
-------------------------------------------------------------
Phone: Fax: Email:
---------------- ------------- ------------
Dietary Restriction : Vegetarian Kosher
---------- ------------
-------------------------------------------------------------------------------
Received: from cnri by ietf.org id aa04915; 17 Sep 96 19:16 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10824;
17 Sep 96 19:16 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <WAA24573 at pad-thai.cam.ov.com>; Tue, 17 Sep 1996 22:43:27 GMT
Received: from ingwwdf.sap-ag.de by MIT.EDU with SMTP
id AA29938; Tue, 17 Sep 96 18:43:24 EDT
Received: from sap-ag.de (sapwdf.wdf.sap-ag.de [147.204.3.3]) by ingwwdf.wdf.sap-ag.de (8.6.12/8.6.9) with SMTP id AAA07072 for <cat-ietf at mit.edu>; Wed, 18 Sep 1996 00:42:43 +0200
Received: from p18509.wdf.sap-ag.de by sap-ag.de with SMTP id AA16004
(5.67b8/IDA-1.5 for <cat-ietf at mit.edu>); Wed, 18 Sep 1996 00:43:05 +0200
Received: (from d019080 at localhost) by p18509.wdf.sap-ag.de (8.7.1/8.7.1) id AAA06786; Wed, 18 Sep 1996 00:41:02 +0200
Date: Wed, 18 Sep 1996 00:41:02 +0200
Message-Id: <199609172241.AAA06786 at p18509.wdf.sap-ag.de>
From: "Martin Rex (d019080)" <martin.rex at sap-ag.de>
To: cat-ietf at mit.edu
Cc: Martin.Rex at sap-ag.de
Subject: C-Bindings: gss_release_buffer()
I'd like to propose a slight change in the current description of
gss_release_buffer (relative to ...-cbind-02.txt):
7.26. gss_release_buffer
Purpose:
Free storage associated with a buffer format name. The storage must
have been allocated by a GSS-API routine. In addition to freeing the
associated storage, the routine will zero the length field in the
buffer parameter.
Parameters:
minor_status Integer, modify
Mechanism specific status code
buffer buffer, modify
The storage associated with the buffer will be
deleted. The gss_buffer_desc object will not
be freed, but its length field will be zeroed.
(1) I'm confused by the term "buffer format name". How about stealing
the wording from the high level spec:
"Allows callers to release the storage associated with an OCTET STRING
buffer allocated by another GSS-API call."
(2) The spec says explicitly that the length field will be zeroed, but it
is quiet about the value field. I assume that the value field
will be zeroed (void * -ed) as well. I'd like to have this explicit
as well, because _I_ would like to return GSS_S_FAILURE when a buffer_t
is passed in with ( buffer->value==NULL && buffer->length!=0 ) or
( buffer->value!=NULL && buffer->length==0 ).
Received: from cnri by ietf.org id aa05329; 17 Sep 96 19:52 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa28645;
17 Sep 96 19:52 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <XAA26182 at pad-thai.cam.ov.com>; Tue, 17 Sep 1996 23:28:32 GMT
Received: from ingwwdf.sap-ag.de by MIT.EDU with SMTP
id AA24728; Tue, 17 Sep 96 19:28:30 EDT
Received: from sap-ag.de (sapwdf.wdf.sap-ag.de [147.204.3.3]) by ingwwdf.wdf.sap-ag.de (8.6.12/8.6.9) with SMTP id BAA07916 for <cat-ietf at mit.edu>; Wed, 18 Sep 1996 01:27:54 +0200
Received: from p18509.wdf.sap-ag.de by sap-ag.de with SMTP id AA17515
(5.67b8/IDA-1.5 for <cat-ietf at mit.edu>); Wed, 18 Sep 1996 01:28:15 +0200
Received: (from d019080 at localhost) by p18509.wdf.sap-ag.de (8.7.1/8.7.1) id BAA06893; Wed, 18 Sep 1996 01:26:13 +0200
Date: Wed, 18 Sep 1996 01:26:13 +0200
Message-Id: <199609172326.BAA06893 at p18509.wdf.sap-ag.de>
From: "Martin Rex (d019080)" <martin.rex at sap-ag.de>
To: cat-ietf at mit.edu
Cc: Martin.Rex at sap-ag.de
Subject: C-Bindings: gss_release_cred()
Reading onward, I'm slightly confused by the description of
gss_release_cred, partly because high-level and c-bindings draw a
different picture. What was the intended behaviour and what is
current implementation practice.
What is gss_release_cred( GSS_C_NO_CREDENTIAL ) now supposed to mean,
and what do existing implementations?
The C-bindings state that the credentials "will be deleted".
It is a local (policy) issue how credentials are "created", so it
it should also be a local (policy) issue, wheter credentials are
destroyed following the last release_cred referencing a specific
handle. This is also how I understand the high-level spec.
Further, the C-Bindings description sounds like it has a process-global
effect on a credential, i.e. if an application process calls
gss_acquire_cred twice with the same gss_name_t (be it a specific
internal name or GSS_C_NO_NAME), and is given the same handle twice,
gss_release_cred should have to be called twice with this handle
before the mechanism should be allowed to release it.
A gssapi mechanism should be required to do ref-counting when handing
out the same handle multiple times or to create and pass out
independent instances of its credentials.
C-Bindings (-gssv2-cbind-02.txt):
-----------
7.27. gss_release_cred
Purpose:
Informs GSS-API that the specified credential handle is no longer
required by the process. When all processes have released a
credential, it will be deleted.
Parameters:
cred_handle gss_cred_id_t, modify, optional
Buffer containing opaque credential
handle. If GSS_C_NO_CREDENTIAL is supplied,
the routine will complete successfully, but
will do nothing.
Function value:
GSS_S_NO_CRED Credentials could not be accessed.
high-level(-gssv2-08.txt):
-----------
2.1.2: GSS_Release_cred call
Input:
o cred_handle CREDENTIAL HANDLE - NULL specifies that
the credential elements used when default credential behavior
is requested be released.
Return major_status codes:
o GSS_S_COMPLETE indicates that the credentials referenced by the
input cred_handle were released for purposes of subsequent
access by the caller. The effect on other processes which may
be authorized shared access to such credentials is a local
matter.
o GSS_S_NO_CRED indicates that no release operation was
performed, either because the input cred_handle was invalid or
because the caller lacks authorization to access the
referenced credentials.
o GSS_S_FAILURE indicates that the release operation failed for
reasons unspecified at the GSS-API level.
Provides a means for a caller to explicitly request that credentials
be released when their use is no longer required. Note that system-
specific credential management functions are also likely to exist,
for example to assure that credentials shared among processes are
properly deleted when all affected processes terminate, even if no
explicit release requests are issued by those processes. Given the
fact that multiple callers are not precluded from gaining authorized
access to the same credentials, invocation of GSS_Release_cred()
cannot be assumed to delete a particular set of credentials on a
system-wide basis.
Final editorial remark: flip the description of the Parameters
min_stat and cred_handle in the C-Bindings and align the description
of the major statu GSS_S_NO_CRED with high-level.
-Martin
Received: from cnri by ietf.org id aa15105; 18 Sep 96 1:10 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13131;
18 Sep 96 1:10 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <EAA06302 at pad-thai.cam.ov.com>; Wed, 18 Sep 1996 04:43:56 GMT
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA05749; Wed, 18 Sep 96 00:43:53 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA17208; Wed, 18 Sep 1996 00:43:54 -0400
Date: Wed, 18 Sep 1996 00:43:54 -0400
Message-Id: <9609180443.AA17208 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Martin Rex <martin.rex at sap-ag.de>
Cc: cat-ietf at mit.edu, Martin.Rex at sap-ag.de
In-Reply-To: Martin Rex's message of Wed, 18 Sep 1996 01:26:13 +0200,
BAD MSG:
<199609172326.BAA06893 at p18509.wdf.sap-ag.de>
ubject: Re: C-Bindings: gss_release_cred()
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Wed, 18 Sep 1996 01:26:13 +0200
From: "Martin Rex (d019080)" <martin.rex at sap-ag.de>
The C-bindings state that the credentials "will be deleted".
It is a local (policy) issue how credentials are "created", so it
it should also be a local (policy) issue, wheter credentials are
destroyed following the last release_cred referencing a specific
handle. This is also how I understand the high-level spec.
My reading has always been that the GSS credentials are merely a
credential "handle", and that the global process credentials are *not*
deleted, but rather the credential handle itself is freed.
- Ted
Received: from cnri by ietf.org id aa20488; 18 Sep 96 8:43 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa07383;
18 Sep 96 8:43 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <MAA18416 at pad-thai.cam.ov.com>; Wed, 18 Sep 1996 12:13:06 GMT
Received: from mail11.digital.com by MIT.EDU with SMTP
id AA08871; Wed, 18 Sep 96 08:12:59 EDT
Received: from us1rmc.bb.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV)
id HAA00681; Wed, 18 Sep 1996 07:59:30 -0400 (EDT)
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA05010; Wed, 18 Sep 96 08:00:50 -0400
Message-Id: <9609181200.AA05010 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Wed, 18 Sep 96 08:00:53 EDT
Date: Wed, 18 Sep 96 08:00:53 EDT
From: "John Wray, Digital DPE, (508) 486-5210 18-Sep-1996 0746" <wray at tuxedo.enet.dec.com>
To: martin.rex at sap-ag.de
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, martin.rex at sap-ag.de
Subject: RE: C-Bindings: gss_release_buffer()
Martin writes:
>I'd like to propose a slight change in the current description of
>gss_release_buffer (relative to ...-cbind-02.txt):
>
> 7.26. gss_release_buffer
>
> Purpose:
>
> Free storage associated with a buffer format name. The storage must
> have been allocated by a GSS-API routine. In addition to freeing the
> associated storage, the routine will zero the length field in the
> buffer parameter.
>
> Parameters:
>
> minor_status Integer, modify
> Mechanism specific status code
>
> buffer buffer, modify
> The storage associated with the buffer will be
> deleted. The gss_buffer_desc object will not
> be freed, but its length field will be zeroed.
>
>
>(1) I'm confused by the term "buffer format name". How about stealing
> the wording from the high level spec:
> "Allows callers to release the storage associated with an OCTET STRING
> buffer allocated by another GSS-API call."
Yes, that's much better. I'll put it in the new revision, although since the
C-bindings don't talk about "OCTET STRING" objects anywhere else, I'll probably
use "contiguous data", or some similar phrase that's already been defined in
the C-bindings document.
>(2) The spec says explicitly that the length field will be zeroed, but it
> is quiet about the value field. I assume that the value field
> will be zeroed (void * -ed) as well. I'd like to have this explicit
> as well, because _I_ would like to return GSS_S_FAILURE when a buffer_t
> is passed in with ( buffer->value==NULL && buffer->length!=0 ) or
> ( buffer->value!=NULL && buffer->length==0 ).
I don't think you should do this. Setting the length field to zero is enough
to indicate "no buffer content". If the app isn't giving you any octets, it
shouldn't matter where it thinks those zero bytes are stored :-)
Consider an application receiving tokens from the network into a pre-allocated
static buffer. The app would do have a gss_buffer_desc object, whose pointer
is set to the address of the buffer. It would do a network read into the
buffer, set the length field of the buffer descriptor to the returned length,
and pass the resulting descriptor to GSSAPI. Requiring that the pointer within
the descriptor be NULL would mean that the app would have to special-case this
(on, for example, the initial token passed to gss_init_sec_context). The code
fragment in the routine description for gss_init_sec_context would also be
wrong if this requirement were added.
It's certainly OK to have GSSAPI set the pointer field to NULL when it's
returning an empty buffer, but GSSAPI shouldn't require the app to do likewise.
I can't remember the exact quote, but the original TCP V4 transition workbook
contained something that's appropriate here, to the effect of "be as precise as
possible in data you generate, and as flexible as possible in data you accept".
This advice is just as good for a procedure-call paradigm as for a network
protocol paradigm.
John
Received: from ietf.org by ietf.org id aa21846; 18 Sep 96 9:35 EDT
Received: from localhost by ietf.org id aa21569; 18 Sep 96 9:27 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-l2tp-00.txt
Date: Wed, 18 Sep 1996 09:27:34 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609180927.aa21569 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 : Layer Two Tunneling Protocol "L2TP"
Author(s) : K. Hamzeh, T. Kolar, M. Littlewood, G. Pall,
J. Taarud, A. Valencia, W. Verthein
Filename : draft-ietf-pppext-l2tp-00.txt
Pages : 67
Date : 09/17/1996
Virtual dial-up allows many separate and autonomous protocol domains to
share common access infrastructure including modems, Access Servers, and
ISDN routers. RFC1661 specifies multiprotocol dial-up via PPP [1]. This
document describes the Layer Two Tunneling Protcol (L2TP) which permits the
tunneling of the link layer (i.e., HDLC, async HDLC) of PPP. Using such
tunnels, it is possible to divorce the location of the initial dial-up
server from the location at which the dial-up protocol connection is
terminated and access to the network provided.
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-l2tp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-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-l2tp-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: <19960917142205.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-l2tp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-l2tp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960917142205.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22327; 18 Sep 96 9:37 EDT
Received: from localhost by ietf.org id aa21607; 18 Sep 96 9:27 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: namedroppers at internic.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-dnsind-tsig-00.txt
Date: Wed, 18 Sep 1996 09:27:42 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609180927.aa21607 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 DNS IXFR, Notification, and
Dynamic Update Working Group of the IETF.
Title : Simple Transaction Signature for DNS
Author(s) : P. Vixie, O. Gudmundsson
Filename : draft-ietf-dnsind-tsig-00.txt
Pages : 7
Date : 09/17/1996
This protocol allows for transaction level authentication using shared
secrets and one way hashing. It can be used to authenticate dynamic
updates as coming from an approved client, or to authenticate responses as
coming from an approved caching/forwarding name server.
No provision has been made here for distributing the shared secrets; it is
expected that a network administrator will statically configure name
servers and clients using some out of band mechanism such as sneaker-net.
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-dnsind-tsig-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-tsig-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-dnsind-tsig-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: <19960917164451.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnsind-tsig-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnsind-tsig-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960917164451.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22328; 18 Sep 96 9:37 EDT
Received: from localhost by ietf.org id aa21561; 18 Sep 96 9:27 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-rfced-info-rekhter-00.txt
Date: Wed, 18 Sep 1996 09:27:31 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609180927.aa21561 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Tag Switching Architecture Overview
Author(s) : Y. Rekhter, B. Davie, D. Katz,
E. Rosen, G. Swallow
Filename : draft-rfced-info-rekhter-00.txt
Pages : 14
Date : 09/17/1996
This document provides an overview of a novel approach to network layer
packet forwarding, called tag switching. The two main components of the
tag switching architecture - forwarding and control - are described.
Forwarding is accomplished using simple label-swapping techniques, while
the existing network layer routing protocols plus mechanisms for binding
and distributing tags are used for control. Tag switching can retain the
scaling properties of IP, and can help improve the scalability of IP
networks. While tag switching does not rely on ATM, it can
straightforwardly be applied to ATM switches. A range of tag switching
applications and deployment scenarios are described.
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-rfced-info-rekhter-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-rekhter-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-rfced-info-rekhter-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: <19960917134721.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-rekhter-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-rekhter-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960917134721.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22352; 18 Sep 96 9:37 EDT
Received: from localhost by ietf.org id aa21540; 18 Sep 96 9:27 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-kandlur-issll-rsvp-mars-00.txt
Date: Wed, 18 Sep 1996 09:27:28 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609180927.aa21540 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Extensions to the MARS model for Integrated Services
Author(s) : R. Guerin, D. Kandlur, D. Williams
Filename : draft-kandlur-issll-rsvp-mars-00.txt
Pages : 5
Date : 09/17/1996
This memo describes an extension to the IP multicast architecture now being
developed by the IP over ATM working group, also known as MARS (Multicast
Address Resolution Server). This extension expands the responsibilities of
the Multicast Server (MCS) to adapt it to the Integrated Services Internet
Architecture and related signaling protocols such as RSVP.
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-kandlur-issll-rsvp-mars-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-kandlur-issll-rsvp-mars-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-kandlur-issll-rsvp-mars-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: <19960917133226.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-kandlur-issll-rsvp-mars-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-kandlur-issll-rsvp-mars-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960917133226.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22685; 18 Sep 96 9:40 EDT
Received: from localhost by ietf.org id aa21588; 18 Sep 96 9:27 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-williams-issll-vcuse-00.txt
Date: Wed, 18 Sep 1996 09:27:37 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609180927.aa21588 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : ATM Virtual Circuit Identification Support for an
RSVP-based Service
Author(s) : D. Williams, R. Guerin, D. Kandlur
Filename : draft-williams-issll-vcuse-00.txt
Pages : 6
Date : 09/17/1996
In this document we present a specification for associating RSVP flows with
Virtual Connections on an ATM network. The text in this document is meant
as an addendum to the text in Subsection 3.2 ``Sending RSVP Messages'' of
the RSVP specification [Bzb+96]. This document specifies a usage of the
Logical Interface Handle (LIH) in the RSVP_HOP Class Object when either a
host or a router is attached to an ATM network. This document also
specifies ATM UNI [For94] signaling semantics for associating a switched
ATM connection with RSVP flows. These ATM UNI semantics use the Broadband
High Layer Information (BHLI) Information Element.
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-williams-issll-vcuse-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-williams-issll-vcuse-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-williams-issll-vcuse-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: <19960917153033.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-williams-issll-vcuse-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-williams-issll-vcuse-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960917153033.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa24030; 18 Sep 96 9:58 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21864;
18 Sep 96 9:58 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <NAA20629 at pad-thai.cam.ov.com>; Wed, 18 Sep 1996 13:22:50 GMT
Received: from mail13.digital.com by MIT.EDU with SMTP
id AA00223; Wed, 18 Sep 96 09:22:48 EDT
Received: from us1rmc.bb.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV)
id JAA22990; Wed, 18 Sep 1996 09:14:33 -0400 (EDT)
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA09151; Wed, 18 Sep 96 09:15:57 -0400
Message-Id: <9609181315.AA09151 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Wed, 18 Sep 96 09:15:57 EDT
Date: Wed, 18 Sep 96 09:15:57 EDT
From: "John Wray, Digital DPE, (508) 486-5210 18-Sep-1996 0800" <wray at tuxedo.enet.dec.com>
To: martin.rex at sap-ag.de
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, martin.rex at sap-ag.de
Subject: RE: C-Bindings: gss_release_cred()
Martin writes:
>Reading onward, I'm slightly confused by the description of
>gss_release_cred, partly because high-level and c-bindings draw a
>different picture. What was the intended behaviour and what is
>current implementation practice.
>
>What is gss_release_cred( GSS_C_NO_CREDENTIAL ) now supposed to mean,
>and what do existing implementations?
Yes, there's a mismatch here between the high-level spec and the C-bindings.
According to the C-bindings, that operation is legal but pointless. The use of
GSS_C_NO_CREDENTIAL indicates that the routime should use "default credential
behavior", which varies, depending on whether the routine needs an
initiator-type or an acceptor-type credential. GSS_C_NO_CREDENTIAL isn't a
real credential handle - you should think of it referring to a "virtual
credential" that is created on demand by the routine that needs it, with
appropriate characteristics for that routine, and then deleted when the routine
has finished with it. For example, if you pass GSS_C_NO_CREDENTIAL to
gss_init_sec_context(), GSSAPI will conceptually create a credential based on
the name given by the default initiator behavior rules, use that credential to
establish a context and then delete the credential (or bind it to the context
so that it gets deleted when the context goes away, if that's how the
implementation works). I say "conceptually" above, because some
implementations won't actually need to create any gssapi structure to represent
the default behavior; those that do shouldn't require their calling apps to be
involved with the deletion of such structures.
I think that the high-level spec text that describes releasing the default
credential should be removed, since it is at odds with the description of
default behavior. The latter implies that a GSSAPI credential structure is
created dynamically if needed, based upon underlying mechanism-specific
credentials, chosen according to the GSSAPI default behavior rules (or
mechanism-specific rules if there's a good reason not to use the GSSAPI rules).
Given this, "deleting the default credential" won't affect future uses of
GSS_C_NO_CREDENTIAL, the next time it's passed to gss_init_sec_context() or
gss_accept_sec_context(), GSSAPI will create a fresh instance of the underlying
credential. Since the GSSAPI credential structure is created automatically if
needed, it should be the implementation's repsonsibility to delete it
automatically, not the application's.
>The C-bindings state that the credentials "will be deleted".
>It is a local (policy) issue how credentials are "created", so it
>it should also be a local (policy) issue, wheter credentials are
>destroyed following the last release_cred referencing a specific
>handle. This is also how I understand the high-level spec.
Yes, that's the intent. The text in the C-bindings that talks about
credential deletion should be modified. gss_release_cred() is a way for the
application to tell GSSAPI that it no longer requires access to a credential
through the presented credential handle. The implication that a credential
must be deleted once all handles that point to it have been released should be
an example of possible GSSAPI behavior, not a requirement.
Note that the term "credential" in the above refers to the GSSAPI-maintained
structure that can refer to multiple mechanism-specific credential elements.
The GSSAPI specs don't say anything about how mechanism-specific credential
elements are created or deleted, only the GSSAPI structure that contains them.
For example, in Kerberos a GSSAPI acceptor credential corresponds roughly to an
entry in a server keytab file. Releasing a handle to such an acceptor
credential isn't expected to actually delete the key from the file, but will
merely delete the association between the credential handle and the key.
>Further, the C-Bindings description sounds like it has a process-global
>effect on a credential, i.e. if an application process calls
>gss_acquire_cred twice with the same gss_name_t (be it a specific
>internal name or GSS_C_NO_NAME), and is given the same handle twice,
>gss_release_cred should have to be called twice with this handle
>before the mechanism should be allowed to release it.
>A gssapi mechanism should be required to do ref-counting when handing
>out the same handle multiple times or to create and pass out
>independent instances of its credentials.
The last sentence above isn't correct - an implementation can pass out multiple
distinct handles that refer to the same underlying credential - it doesn't have
to create independent instances of the credential itself. This is the model
that was intended - I would characterize the ability to return the same handle
from multiple calls to gss_acquire_cred() as an oversight, and indeed
reference-counting is the only obvious way of making this alternative model
behave in the same way as the "distinct handles" model. The simplest thing
would perhaps be to add text prohibiting this alternative model, requiring that
distinct handles are always returned by each succesful call to
gss_acquire_cred(). That would certainly make the expected behavior clearer,
both for implementors and for applications.
It would also allow us to clear up a related ambiguity in gss_add_cred(), for
the "modify-in-place" operation. If I call gss_acquire_cred() twice, and
obtain two handles A and B for the same credential, then use handle A to add a
new mechanism via gss_add_cred(), is the new mechanism visible through handle
B? If an implementation is allowed to return the same handle from multiple
calls to gss_acquire_cred(), then the answer would have to be "yes", otherwise
applications would see differing behaviors between GSSAPI implementations that
do this and those that don't. If distinct handles are required to be returned
by gss_acquire_cred(), then we can (and should) specify whether modifications
made by gss_add_cred() will be visible via multiple handles.
We also should tighten up the spec of gss_add_cred() to prohibit attempts to
change credentials accessed via GSS_C_NO_CREDENTIAL. Since this isn't a real
credential handle, but merely a request for default behavior, we shouldn't give
the impression that an application can alter default behavior for future calls
by invoking gss_add_cred() specifying input_cred to be GSS_C_NO_CREDENTIAL, and
to attempt a modify-in-place operation - we should explicitly prohibit this
combination.
John
Received: from ietf.org by ietf.org id aa25826; 19 Sep 96 9:57 EDT
Received: from localhost by ietf.org id aa24716; 19 Sep 96 9:40 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: hubmib at hprnd.rose.hp.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-hubmib-repeater-dev-03.txt
Date: Thu, 19 Sep 1996 09:39:59 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609190940.aa24716 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 IEEE 802.3 Hub MIB Working
Group of the IETF.
Title : Definitions of Managed Objects for
IEEE 802.3 Repeater Devices
Author(s) : K. De Graaf, D. Romascanu, D. McMaster
Filename : draft-ietf-hubmib-repeater-dev-03.txt
Pages : 90
Date : 09/18/1996
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for managing IEEE 802.3 10
and 100 Mb/second baseband repeaters based on IEEE Std 802.3 Section 30,
"10 & 100 Mb/s Management," October 26, 1995.
This memo does not specify a standard for the Internet community.
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-hubmib-repeater-dev-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-hubmib-repeater-dev-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-hubmib-repeater-dev-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: <19960918150114.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-hubmib-repeater-dev-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-hubmib-repeater-dev-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960918150114.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25823; 19 Sep 96 9:57 EDT
Received: from localhost by ietf.org id aa24679; 19 Sep 96 9:39 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: atommib at thumper.bellcore.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-atommib-atm2-07.txt
Date: Thu, 19 Sep 1996 09:39:40 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609190939.aa24679 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 AToM MIB Working Group of
the IETF.
Title : Definitions of Supplemental Managed Objects
for ATM Management
Author(s) : F. Ly, M. Noto, A. Smith, K. Tesink
Filename : draft-ietf-atommib-atm2-07.txt
Pages : 92
Date : 09/18/1996
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols
in the Internet community.
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-atommib-atm2-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-atm2-07.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-atommib-atm2-07.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: <19960918102422.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-atommib-atm2-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-atommib-atm2-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960918102422.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25824; 19 Sep 96 9:57 EDT
Received: from localhost by ietf.org id aa24696; 19 Sep 96 9:39 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-battle-instresmib-00.txt
Date: Thu, 19 Sep 1996 09:39:47 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609190939.aa24696 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Definitions of Managed Objects for Instance Reservation
Author(s) : D. Battle, U. Haebel
Filename : draft-battle-instresmib-00.txt
Pages : 13
Date : 09/18/1996
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes a basic set of managed objects for
instance reservation in other MIB tables.
This memo does not specify a standard for the Internet community.
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-battle-instresmib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-battle-instresmib-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-battle-instresmib-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: <19960918105624.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-battle-instresmib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-battle-instresmib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960918105624.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02823; 19 Sep 96 13:31 EDT
Received: from relay.hq.tis.com by ietf.org id aa02706; 19 Sep 96 13:26 EDT
Received: by relay.hq.tis.com; id NAA11041; Thu, 19 Sep 1996 13:23:30 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma011035; Thu, 19 Sep 96 13:23:04 -0400
Received: from antares.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA01678; Thu, 19 Sep 96 13:22:16 EDT
Message-Id: <9609191722.AA01678 at tis.com>
To: ietf at ietf.org
Subject: ANNOUNCE: TIS/DNSSEC Beta 1.3.1 is now available worldwide
Date: Thu, 19 Sep 1996 13:22:56 -0400
Sender:ietf-request at ietf.org
From: Olafur Gudmundsson <ogud at tis.com>
Source-Info: From (or Sender) name not authenticated.
We are pleased to announce that the third Beta release of
TIS/DNSSEC Beta-1.3.1 is now available. This is exportable with
the restrictions identified in the following paragraph.
/*
* Trusted Information Systems, Inc. has received approval from the
* United States Government for export and reexport of TIS/DNSSEC
* software from the United States of America under the provisions of
* the Export Administration Regulations (EAR) General Software Note
* (GSN) license exception for mass market software. Under the
* provisions of this license, this software may be exported or
* reexported to all destinations except for the embargoed countries of
* Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria. Any export
* or reexport of TIS/DNSSEC software to the embargoed countries
* requires additional, specific licensing approval from the United
* States Government.
*/
This version is a implementation of the current DNSSEC draft and it is
based on bind-4.9.4-p1,it uses RSAREF for signature generation and
verification, you need to retrieve your own copy from RSA.
We are actively seeking beta testers.
Feel free to test against our secure nameserver for zone sd-bogus.tis.com
which is served from uranus.hq.tis.com.
We are also making a DNSSEC enhanced version of DIG available,
in executable form for popular platforms. This version of dig is
extended to query sd-bogus and other secure servers. There are
no export restrictions on the executables
The distribution is available as
ftp://ftp.tis.com/pub/DNSSEC/sec_bind494-b131.tar.gz
Or you can access our web page at
http://www.tis.com/docs/research/network/dns.html
The new dig a sunos4.x executable versions are
ftp://ftp.tis.com/pub/DNSSEC/sdig.sunos4.gz
Other versions will be made available as
ftp://ftp.tis.com/pub/DNSSEC/sdig.<OS>.gz
If you have any questions or problems please send a note to
tisdnssec-support at tis.com.
If you compile the new dig on a popular platform that we do not have
an executable for please let us know.
Enjoy,
Olafur Gudmundssonogud at tis.com
(301)-854-6889(phone)(301)-854-5363 FAX
Received: from ietf.org by ietf.org id aa10448; 19 Sep 96 19:17 EDT
Received: from lighthouse.homeport.org by ietf.org id aa10372;
19 Sep 96 19:13 EDT
Received: (adam at localhost) by homeport.org (8.6.9/8.6.9) id TAA07129; Thu, 19 Sep 1996 19:18:47 -0500
Sender:ietf-request at ietf.org
From: Adam Shostack <adam at homeport.org>
Message-Id: <199609200018.TAA07129 at homeport.org>
Subject: Re: ANNOUNCE: TIS/DNSSEC Beta 1.3.1 is now available worldwide
To: Olafur Gudmundsson <ogud at tis.com>
Date: Thu, 19 Sep 1996 19:18:46 -0500 (EST)
Cc: ietf at ietf.org
In-Reply-To: <9609191722.AA01678 at tis.com> from "Olafur Gudmundsson" at Sep 19, 96 01:22:56 pm
X-Mailer: ELM [version 2.4 PL24 ME8b]
Content-Type: text
Content-Length: 743
Source-Info: From (or Sender) name not authenticated.
Olafur Gudmundsson wrote:
| We are pleased to announce that the third Beta release of
| TIS/DNSSEC Beta-1.3.1 is now available. This is exportable with
| the restrictions identified in the following paragraph.
|
| This version is a implementation of the current DNSSEC draft and it is
| based on bind-4.9.4-p1,it uses RSAREF for signature generation and
| verification, you need to retrieve your own copy from RSA.
For those interested in working with this outside the US, there is a
package called RSAEuro, which was developed outside the US, and is
call compatible with RSAref.
ftp://idea.dsi.unimi.it/pub/crypt/code/rsaeuro-1.02.tar.gz
Adam
--
"It is seldom that liberty of any kind is lost all at once."
-Hume
Received: from ietf.org by ietf.org id aa15437; 19 Sep 96 23:04 EDT
Received: from BIG-SCREW.MIT.EDU by ietf.org id aa14509; 19 Sep 96 23:00 EDT
Received: by big-screw
id AA03126; Thu, 19 Sep 96 22:59:18 -0400
Message-Id: <32420858.505B at mit.edu>
Date: Thu, 19 Sep 1996 22:58:32 -0400
Sender:ietf-request at ietf.org
From: "Jeffrey I. Schiller" <jis at mit.edu>
Reply-To: jis at mit.edu
Organization: Massachusetts Institute of Technology
X-Mailer: Mozilla 3.0 (Macintosh; U; 68K)
Mime-Version: 1.0
To: ipsec at tis.com, ietf at ietf.org
Subject: Security AD Statement on IPSEC Key Management
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
-----BEGIN PGP SIGNED MESSAGE-----
Introduction
Standardized security technology is urgently needed on the Internet
today. The IPSEC Working Group has been working to provide solutions
applicable to the IP Layer of the protocol stack. Over a year ago,
consensus was reached on the packet formats necessary to provide data
authentication, integrity and confidentiality. However the mechanism to
exchange required cryptographic material was not yet ready for
standardization.
Since then the IPSEC Working Group has been struggling with several
competing key management proposals. To have competing proposals within
an IETF working group is neither new nor novel. However the time comes
when either the proponents of the various proposals come to consensus
(along with the rest of the working group) or a decision among them
has to be made. That time is now.
In Montreal (at the June IETF meeting) I saw several factions at work
in the IPSEC working group. There were people supporting each of the
proposed key management solutions and a larger number of people who
were looking for a single solution to emerge, but who themselves were
not in a position to have a technical opinion one way or the other. But
one thing was clear, they wanted a solution and they wanted it then.
Shortly after the meeting I was approached by several people offering
to have a "design team" meeting with the principals behind the various
proposals. The goal of the team was to come up with a compromise that
all could live with. I considered this very good news, but I was also
cautious. The last thing I wanted was to have a working group meeting
at the December 1996 IETF and still be where we were in Montreal,
namely without a solution! To this end I established a time limit. The
charge to the design team was to come up with a compromise solution
(or enough progress on a compromise) by September 1. After September
1, if the working group could not decide upon a course of action, then
I would step in as Security Area Director and propose one myself.
As those of you on the IPSEC list already know, the design team failed
in their effort to come up with a compromise. I am both saddened and
disappointed by this outcome.
The purpose of this document is to end the controversy and establish
a productive direction for future work.
History
To understand the situation requires a bit of history and explanation.
Although most Internet problems can be solved by a single protocol, this
doesn't always have to be the case. For example, we have TCP and UDP
which both provide a transport service, but with very different
characteristics to address different problem domains. Similarly we have
both the RIP and OSPF routing protocols. Each protocol has features
different from the other, and each has its appropriate domain of
applicability.
Why is IPSEC different? To understand this we have to go back to the
original decision reached by the IETF in the IPv6 selection process.
Specifically the IETF decided that security, namely IPSEC, was a
mandatory requirement for a compliant implementation of IPv6. This was
decided upon because the community felt that without such a mandatory
feature, security would not be implemented in a lot of products, even
though there is a pressing need for security on the Internet. The
reasons for this belief are many and varied and beyond the scope of this
document. Suffice it to say that IPSEC technology is mandatory in IPv6.
The mandatory nature of IPSEC means that for its various protocols,
several variants may exist, but one of each class of protocol will
need to be designated as mandatory to provide guidance to vendors
wishing to build IPv6 compliant versions of products.
The mandatory to implement protocols may not necessarily be the ideal
solution for any particular problem. Instead they are selected to
provide two basic requirements:
o Strong Security
o Interoperability
The goal is for two compliant implementations of IPSEC to be able to
communicate securely because they, at a minimum, have the mandatory to
implement protocols common between them. They may have other protocols,
such as other Authentication Header (AH) and Encapsulated Security
Protocol (ESP) transforms, in common which they may negotiate the use of
instead of the mandatory protocols.
The mandatory transforms may not always be the ideal approach for a
particular network application. For example, the mandatory ESP
transform involves the use of the U.S. Data Encryption Standard
(DES). This encryption algorithm is widely regarded as being secure
enough for most applications. It is also commonly recognized that DES
is a slow algorithm and applications requiring high speed data
transfer (in the absence of high speed DES hardware) may elect to use
a faster cipher such as the International Data Encryption Algorithm
(IDEA) or RSA Data Security's RC2 or RC4 ciphers.
Analysis
Keeping in mind that the primary goal of the mandatory protocols is to
provide strong security and interoperability, I have read and evaluated
the approaches in the two main contenders for the IPSEC key management
mandatory standard, SKIP and ISAKMP/Oakley.
ISAKMP/Oakley
ISAKMP defines a Security Association management protocol for
establishing security contexts and keys between a pair of hosts on the
Internet. By itself it does not define a key management function. Oakley
provides a key management function which can operate within the ISAKMP
protocol. The combination provides for complete security association and
cryptographic key material management.
Oakley itself provides several protocol variations which trade-off
between protocol overhead (the number of messages sent between
communicating hosts) and services provided (such as identity
confidentiality).
ISAKMP/Oakley imposes a cost of several packet exchanges between host
pairs before secure communication can take place. There is no per-packet
overhead to use ISAKMP/Oakley (other then the AH and ESP header overhead
itself) once associations are in place. For a set of hosts which
communicate with each other on a frequent basis, it is expected that
associations will remain in place and the overhead of setting new ones
up will not be a significant factor.
The primary disadvantage of the ISAKMP/Oakley approach is that it
imposes significant overhead in the case where hosts communicate
infrequently as it is likely that associations will not exist when
needed and will have to be setup.
If either party to a security association looses or changes state, so
that existing associations are no longer operative, then a new set of
security associations can be established. Messages, protected by the new
associations, can communicate the demise of the failed associations.
SKIP
The SKIP proposal is based on in-line keying. Each packet is encrypted
in a key which is provided in the packet itself, encrypted in a key that
is setup between the communicating host pair. SKIP's advantage is that
the protocol for setting up inter-host keys is fairly lightweight. If
both hosts already have the other hosts public key certificate, no
packet exchanges are required as the arriving data packet will contain
sufficient information for the receiving host to compute the shared key
and respond accordingly.
Computing the shared key requires significant computation
(exponentiation). However a communicating host pair can choose to cache
their shared keys to avoid this computational overhead. There is a
trade-off between computation of shared keys and secure storage to hold
already computed keys.
In SKIP if a received packet cannot be decrypted, there is little
fallback available as SKIP does not naturally support multiple security
associations. Put another way, the lightweight key management does not
have a heavyweight fallback in the event that key management fails for
any reason. The result is that messages must be sent without security
enhancements to indicate the failure. However such messages will be
indistinguishable from forged messages originated by an attacker for the
purpose of disrupting communication.
The implication of the lightweight approach of SKIP is that no
significant negotiation of algorithms, certificates and other options
are possible. The assumption is that certain parameters, such as the
Diffie Hellman prime and generator will be constant among members of a
community of hosts using SKIP. Among a small community of hosts, e.g.,
within an autonomous system (AS), such parameters need not be negotiated
in real-time, but rather can be configured in advance in the hosts. If
at some future point they need to be changed, the amount of management
overhead necessary is bounded by the size of the AS.
SKIP will also likely be faster at recovery from normal system failure
(reboot) when a host communicates with a significant number of peers. In
this situation the lightweight approach provides for faster
re-establishment of secure communication.
Note: Some features of SKIP, including Certificate Discovery and
Algorithm Discovery improve its ability to cope with some classes of
failures. However this additional mechanism comes at the cost of
additional packet exchanges and protocol complexity. It is my opinion
that SKIP could be further modified to deal with these issues as well as
ISAKMP/Oakley does. However I believe such a modified protocol will be
as complicated if not more so then the ISAKMP/Oakley protocol
combination.
Conclusion
I had hoped that the design team would have recognized that each of the
two proposals above have domains where they are particularly well
suited. It is conceivable to this author that a merged mechanism could
exist that provides the benefits of SKIP within an AS (or similar
community) and ISAKMP/Oakley when more protocol negotiation is required.
A simple (from my point of view) solution would be to require both SKIP
and ISAKMP/Oakley be implemented in a compliant IPv6 protocol stack.
However it is clear to me that there is significant overlap of
functionality between these two protocols and without a compromise
(presumably a compromise protocol would result in a lot of shared
mechanism and code in implementations) implementors would have to write
a lot of excess code.
Therefore we have to pick one approach as the mandatory solution. This
does not mean that the other approach cannot become an ELECTIVE Internet
Standard.
Going back to my original view of the goal behind the "mandatory"
approach leads me to conclude that if we must pick between ISAKMP/Oakley
and SKIP, then ISAKMP/Oakley should be the mandatory standard. My
rationale is simple. It is my belief that given an arbitrarily chosen
pair of hosts, it is likelier that an ISAKMP/Oakley approach will result
in a working security association than SKIP. Furthermore going back to
the original working group charter, the ISAKMP/Oakley approach more
closely follows the goals established in the charter to the IKMP portion
of the IPSEC work.
I would like to see the IPSEC working group create three sets of RFCs.
o A Set of RFCs which fully define the ISAKMP/Oakley approach. These
RFCs will follow the normal IETF standards track ultimately resulting in
a protocol that is ELECTIVE for IPv4 and is MANDATORY for IPv6.
o A Set of RFCs which fully define the SKIP approach. These RFCs will
follow the normal IETF standards tack ultimately resulting in a protocol
that is ELECTIVE for IPv4 and is ELECTIVE for IPv6.
o One or more RFCs that describe the application domain for
ISAKMP/Oakley and SKIP.
Although I believe that ISAKMP/Oakley should become the IPv6 Mandatory
protocol, I also believe that there exist significant domains of
application where the SKIP approach makes more sense. I would like the
working group to address this.
Recommendation
I formally recommend, as Security Area Director, that the charter for
the IPSEC working group be amended to charge the working group with the
tasks above. The arguments between the ISAKMP/Oakley and SKIP factions
should no longer be considered appropriate discussion for the working
group, either at its in person meetings or on the working group mailing
list. If some people would like to continue that line of discussion they
are welcome to form a separate mailing list, not part of the IETF.
Proposed New Charter (with change bars)
IP Security Protocol (ipsec) Charter
Chair(s)
* Ran Atkinson <rja at cisco.com>
* Paul Lambert <palamber at us.oracle.com>
Security Area Director(s):
* Jeffrey Schiller <jis at mit.edu>
Mailing List Information
* General Discussion:ipsec at tis.com
* To Subscribe: ipsec-request at tis.com
* Archive: ftp://ftp.tis.com/pub/lists/ipsec
Description of Working Group
Rapid advances in communication technology have accentuated the need
for security in the Internet. The IP Security Protocol Working Group
(IPSEC) will develop mechanisms to protect client protocols of IP. A
security protocol in the network layer will be developed to provide
cryptographic security services that will flexibly support
combinations of authentication, integrity, access control, and
confidentiality.
The protocol formats for the IP Authentication Header (AH) and IP
Encapsulating Security Payload (ESP) will be independent of the
cryptographic algorithm. The preliminary goals will specifically
pursue host-to-host security followed by subnet-to-subnet and
host-to-subnet topologies.
Protocol and cryptographic techniques will also be developed to
support the key management requirements of the network layer
security. The Internet Key Management Protocol (IKMP) will be
specified as an application layer protocol that is independent of the
| lower layer security protocol. The protocol will be based on the
| ISAKMP/Oakley work begun in:
|
| <draft-ietf-ipsec-isakmp-05.txt>,
| <draft-ietf-ipsec-oakley-01.txt> and
| <draft-ietf-ipsec-isakmp-oakley-00.txt>.
|
| A follow on work item may incorporate mechanisms based on SKIP as
| defined in:
|
| <draft-ietf-ipsec-skip-07.txt>
|
| and related documents. Flexibility in the protocol will allow
| eventual support of Key Distribution Centers (KDC), such as are used
| by Kerberos.
Goals and Milestones
Done
Submit Internet-Draft of Internet Key Management Protocol to the IESG
for consideration as a Proposed Standard.
Done
Post as an Internet-Draft the IP Security Protocol.
Done
Post as an Internet-Draft the specification for Internet key
management.
Done
Conduct initial interoperability testing of Encapsulating Security
payload (ESP) and Authentication Header (AH).
| Done
Submit revised Internet-Drafts for ESP, AH, and IP Security
Architecture.
| Dec 96
Submit revised Internet-Drafts of IP Security Architecture, ESP, and AH
to the IESG for consideration as Draft Standards.
| Jan 97
| Submit Internet-Draft of the Internet Key Management Protocol (IKMP).
| based on ISAKMP/Oakley to the IESG for consideration as a Proposed
| Standard.
| Jul 97
| Submit IKMP to IESG for consideration as a Draft Standard.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMkHj78UtR20Nv5BtAQEiAgP/XTqrl8Wn4jFpOgtukCbIgDUrsqzKiMDy
HCl6pX4BbXGpdiHlayCdhS1g5zbdwRa4J4TQg8sESbDkD49Zcs4a9bIDjY31gIB4
HnP7twW1/sEls5Rp/j9vBHTDHQIMJFVWluuJOrQQfPxcLAEFjH+3enfFRAJXQVmo
SOwHCHPmW7I=
=mr47
-----END PGP SIGNATURE-----
Received: from ietf.org by ietf.org id aa03548; 20 Sep 96 16:54 EDT
Received: from cnri by ietf.org id aa03186; 20 Sep 96 16:41 EDT
Received: from shiva1.cac.washington.edu by CNRI.Reston.VA.US id aa01727;
20 Sep 96 16:41 EDT
Received: from localhost (lrs at localhost) by shiva1.cac.washington.edu (8.7.5+UW96.09/8.7.3+UW96.09) with SMTP id NAA14722 for <ietf at cnri.reston.va.us>; Fri, 20 Sep 1996 13:41:24 -0700
Date: Fri, 20 Sep 1996 13:41:23 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Lori Stevens <lrs at cac.washington.edu>
Reply-To: Lori Stevens <lrs at cac.washington.edu>
To: ietf at CNRI.Reston.VA.US
Subject: IMAP Meeting Update
Message-ID: <Pine.ULT.3.95.960920111635.5238F-100000 at shiva1.cac.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
2nd International INTERNET MESSAGE ACCESS PROTOCOL Meeting
Seattle, Nov 6-8, 1996
UPDATE: An agenda for this meeting is now available:
http://www.washington.edu/imap/meeting.2nd/agenda.html
For those interested in the Application Configuration Access Protocol,
there will be an ACAP w.g. mtg immediately following the IMAP mtg.
NOTE: If you plan to come, please register soon!!
On October 6th the meeting fee goes from $225.00 to $300.00.
At the Westin Hotel, the group rate of $125.00/night (guaranteed until
October 6th) also applies to two days before and two days after the
meeting. The Westin's 1-800 number may not have complete information
about our group rate package so use Seattle reservations at 1-206-728-1000
(hours are 8:00-17:00 PDT).
Received: from ietf.org by ietf.org id aa04240; 23 Sep 96 14:07 EDT
Received: from localhost by ietf.org id aa03638; 23 Sep 96 13:37 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: http-wg at cuckoo.hpl.hp.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-http-digest-aa-05.txt
Date: Mon, 23 Sep 1996 13:37:22 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609231337.aa03638 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.
Note: This revision reflects comments received during the last call period.
Title : An Extension to HTTP : Digest Access Authentication
Author(s) : J. Franks, P. Hallam-Baker, J. Hostetler,
P. Leach, A. Luotonen, E. Sink, L. Stewart
Filename : draft-ietf-http-digest-aa-05.txt
Pages : 13
Date : 09/23/1996
The protocol referred to as "HTTP/1.0" includes the specification for a
Basic Access Authentication scheme. This scheme is not considered to be a
secure method of user authentication, as the user name and password are
passed over the network as clear text. A specification for a different
authentication scheme is needed to address this severe limitation. This
document provides specification for such a scheme, referred to as "Digest
Access Authentication". Like Basic, Digest access authentication verifies
that both parties to a communication know a shared secret (a password);
unlike Basic, this verification can be done without sending the password in
the clear, which is Basic's biggest weakness. As with most other
authentication protocols, the greatest sources of risks are usually found
not in the core protocol itself but in policies and procedures surrounding
its use.
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-digest-aa-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-digest-aa-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-http-digest-aa-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: <19960923133310.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-digest-aa-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-digest-aa-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960923133310.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa07123; 23 Sep 96 15:45 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa25680;
23 Sep 96 15:45 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <TAA16541 at pad-thai.cam.ov.com>; Mon, 23 Sep 1996 19:14:05 GMT
From: "<" <@cbgw1.lucent.com:cking at arch4.ho.att.com>
Received: from cbgw1.att.com by MIT.EDU with SMTP
id AA04471; Mon, 23 Sep 96 15:13:37 EDT
Date: 23 Sep 96 15:21:00 -0400
Received: from arch4.ho.att.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2)
id PAA22902; Mon, 23 Sep 1996 15:07:06 -0400
Received: from archmail1.UUCP by arch4.ho.att.com (4.1/EMS-1.2 GIS)
id AA28415; Mon, 23 Sep 96 15:12:33 EDT
Received: by arch4 with Microsoft Mail
id <3246E120 at arch4>; Mon Sep 23 15:12 EDT 1996
Original-From: "King, Christopher" <cking at arch4.ho.att.com>
To: "'cat-ietf at MIT.EDU'" <cat-ietf at mit.edu>
Subject: Authorization API
Original-Date: Mon Sep 23 15:21 EDT 1996
Message-Id: <3246E120 at arch4>
Encoding: 20 TEXT
X-Mailer: Microsoft Mail V3.0
My name is Chris King. I would like to publish an extension to the
GSSAPI
that focuses on authorization. A standard method of calling an ACL or
Capability list. It's not as complex as
draft-ietf-xgssapi-acc-cntrl-01.txt. It requires the user is
authenticated before you call the API. I'm assuming
a successful GSS bind.
What is the proceedure for publishing such a document, otherthan the
standard writers guide. Is this something that CAT could use or should I
persue a RFC?
Thanks
_________________________________________________________________
Christopher King Information Security (INFOSEC) Engineering, INC
Security Consultant 27 Billerica Road
cking at infoseceng.com Chelmsford, MA 01824 Pager# 1-800-467-3700
www.infoseceng.com Office# (508) 256-4494 Pin# 602-0100
_________________________________________________________________
Received: from cnri by ietf.org id aa24826; 24 Sep 96 8:18 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21671;
24 Sep 96 8:18 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <LAA17292 at pad-thai.cam.ov.com>; Tue, 24 Sep 1996 11:50:46 GMT
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA28539; Tue, 24 Sep 96 07:50:45 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <LAA17288 at pad-thai.cam.ov.com>; Tue, 24 Sep 1996 11:50:44 GMT
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id HAA00488; Tue, 24 Sep 1996 07:50:39 -0400
Message-Id: <199609241150.HAA00488 at winkl.cam.ov.com>
To: cking at infoseceng.com, cking at arch4.ho.att.com
Cc: cat-ietf at mit.edu
Subject: Re: Authorization API
Date: Tue, 24 Sep 1996 07:50:37 -0400
From: John Linn <linn at cam.ov.com>
Chris,
I'd suggest preparing this document and submitting it as an
Internet-Draft, and then requesting review and discussion within the
CAT-WG. Basically, there's little procedure involved in
Internet-Draft publication beyond use of formatting as described
for RFC authorship; I-D submissions can be sent to:
internet-drafts at ietf.org.
--jl
------- Forwarded Message
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <TAA16541 at pad-thai.cam.ov.com>; Mon, 23 Sep 1996 19:14:05 GMT
From: "<"<@cbgw1.lucent.com:cking at arch4.ho.att.com>
Received: from cbgw1.att.com by MIT.EDU with SMTP
id AA04471; Mon, 23 Sep 96 15:13:37 EDT
Date: 23 Sep 96 15:21:00 -0400
Received: from arch4.ho.att.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2)
id PAA22902; Mon, 23 Sep 1996 15:07:06 -0400
Received: from archmail1.UUCP by arch4.ho.att.com (4.1/EMS-1.2 GIS)
id AA28415; Mon, 23 Sep 96 15:12:33 EDT
Received: by arch4 with Microsoft Mail
id <3246E120 at arch4>; Mon Sep 23 15:12 EDT 1996
Original-From: "King, Christopher" <cking at arch4.ho.att.com>
To: "'cat-ietf at MIT.EDU'" <cat-ietf at mit.edu>
Subject: Authorization API
Original-Date: Mon Sep 23 15:21 EDT 1996
Message-Id: <3246E120 at arch4>
Encoding: 20 TEXT
X-Mailer: Microsoft Mail V3.0
My name is Chris King. I would like to publish an extension to the
GSSAPI
that focuses on authorization. A standard method of calling an ACL or
Capability list. It's not as complex as
draft-ietf-xgssapi-acc-cntrl-01.txt. It requires the user is
authenticated before you call the API. I'm assuming
a successful GSS bind.
What is the proceedure for publishing such a document, otherthan the
standard writers guide. Is this something that CAT could use or should I
persue a RFC?
Thanks
_________________________________________________________________
Christopher King Information Security (INFOSEC) Engineering, INC
Security Consultant 27 Billerica Road
cking at infoseceng.com Chelmsford, MA 01824 Pager# 1-800-467-3700
www.infoseceng.com Office# (508) 256-4494 Pin# 602-0100
_________________________________________________________________
------- End of Forwarded Message
Received: from ietf.org by ietf.org id aa27118; 24 Sep 96 9:59 EDT
Received: from cnri by ietf.org id aa26732; 24 Sep 96 9:51 EDT
Received: from dirty.research.bell-labs.com by CNRI.Reston.VA.US id aa12811;
24 Sep 96 9:51 EDT
Received: from research.bell-labs.com by dirty; Tue Sep 24 09:50:33 EDT 1996
Received: from allegra.tempo.att.com by research; Tue Sep 24 09:49:05 EDT 1996
Received: from nfm (nfm.tempo.att.com) by allegra.tempo.att.com; id AA08338; Tue, 24 Sep 96 09:49:05 EDT
Received: by nfm; id AA07706; Tue, 24 Sep 96 09:49:03 EDT
Date: Tue, 24 Sep 96 09:49:03 EDT
Sender:ietf-request at ietf.org
From: Nick Maxemchuk <nfm at research.bell-labs.com>
Message-Id: <9609241349.AA07706 at nfm>
To: apc at ee.nthu.edu.tw, apc_members at hornbill.ee.nus.sg,
commsoft at cc.bellcore.com, enternet at bbn.com, ietf at CNRI.Reston.VA.US,
itc at fokus.gmd.de, multicomm at cc.bellcore.com, tccc at cs.umass.edu
Subject: Call for Papers
Source-Info: From (or Sender) name not authenticated.
CALLFOR PAPERS
IEEEJournalon Selected Areas in Communications
COPYRIGHT AND PRIVACY PROTECTION
Significant investmentsare nowbeing made worldwide todevelopan
infrastructure for on-line services andelectronic commerce. Amajor
impediment is the lack of effective protection of copyright for
contentowners and of privacy for users. Digital data can be easily
copied and redistributed widelywithoutany loss of fidelity. One
promising idea is to discourageillicitdistribution bywatermarking
digitalobjectswith hidden copyright messages to proclaim ownership
and unique identifiers to help trace pirates. The techniques of
information hiding are in many ways related to mechanisms that can be
used toprotectthe anonymity of systemusers by concealing address,
location and routing information. The problem becomes even more
interesting when privacy protection andcopyright protection must be
combined in thesame system.
We seekfundamental papers on watermarking of digital data, on
techniques for anonymous communications, and design andanalysis of
systemsthat protect copyright and/or privacy.A partial list of
topics is as follows:
+ watermarking of digital data
+ anonymous communications
+ steganography
+ covert andsubliminal channels in networks protocols
+ combining copyright and privacy protection
+ experiments and attacks
+ tradeoffs between performance and security
Prospective authors should email their manuscripts (PostScript format
only) or send six hard copies to one ofthe Guest Editors listed
below, according to thefollowing schedule. Please direct all email
enquiries to slow at ee.mu.oz.au.
ManuscriptDue:March 1, 1997
AcceptanceNotification:August 1, 1997
Final Manuscript Due:November 1, 1997
Publication Date:2nd Quarter 1998
Ross AndersonIngemarCox
Cambridge University Computer LabNEC Research
Pembroke Street4 Independence Way
Cambridge CB2 3QG, U.K.Princeton NJ 08540, USA
Tel: +44 1223 33 47 33Tel: +1 609 951 2722
Fax: +44 1223 33 46 78Fax: +1 609 951 2482
Email: ross.anderson at cl.cam.ac.ukEmail: ingemar at research.nj.nec.com
Steven LowNicholas Maxemchuk
Dept. of Electrical ElectronicEngr.ATT Laborataries
University of Melbourne600 Mountain Ave.
Parkville, Vic 3052, AustraliaMurray Hill NJ 07974, USA
Tel: +613 92879205Tel: +1 908 582 6240
Fax: +613 92879188Fax: +1 908 582 5807
Email: slow at ee.mu.oz.auEmail:nfm at research.att.com
Received: from ietf.org by ietf.org id aa28127; 24 Sep 96 10:07 EDT
Received: from localhost by ietf.org id aa27588; 24 Sep 96 10:02 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-andrades-framing-ext-00.txt
Date: Tue, 24 Sep 1996 10:02:55 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609241002.aa27588 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : QOSPPP Framing Extensions to PPP
Author(s) : R. Andrades, F. Burg
Filename : draft-andrades-framing-ext-00.txt
Pages : 20
Date : 09/23/1996
The Point-to-Point Protocol (PPP) [2] provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP
datagrams are often encapsulated in HDLC frames [1] when used over
standard analog modems.
This document describes the extensions to PPP encapsulation and HDLC
framing to support Quality of Service (QoS) over low bandwidth links.
This document is a submission to the IETF ISSLL working group. Comments are
solicited and should be addressed to the working group's mailing list at
issll at mercury.lcs.mit.edu and/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-andrades-framing-ext-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-andrades-framing-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-andrades-framing-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: <19960923110853.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-andrades-framing-ext-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-andrades-framing-ext-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960923110853.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28589; 24 Sep 96 10:10 EDT
Received: from localhost by ietf.org id aa27570; 24 Sep 96 10:02 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: issll at mercury.lcs.mit.edu, 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-issll-isslow-mcml-00.txt
Date: Tue, 24 Sep 1996 10:02:33 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609241002.aa27570 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 Integrated Services over
Specific Link Layers Working Group of the IETF.
Title : The Multi-Class Extension to Multi-Link PPP
Author(s) : C. Bormann
Filename : draft-ietf-issll-isslow-mcml-00.txt
Pages : 18
Date : 09/23/1996
A companion document describes an architecture for providing integrated
services over low-bitrate links, such as modem lines, ISDN B-channels, and
sub-T1 links [1]. The main components of the architecture are: a real-time
encapsulation format for asynchronous and synchronous low-bitrate links, a
header compression architecture optimized for real-time flows, elements of
negotiation protocols used between routers (or between hosts and routers),
and announcement protocols used by applications to allow this negotiation
to take place.
This document proposes the solution for the real-time encapsulation format
part of the architecture. The general approach is to start from the
PPP Multilink fragmentation protocol [2] and provide a small number of
extensions to add functionality and reduce the overhead.
This document is a product of the IETF ISSLL working group.
It is also a submission to the IETF PPPEXT working group. Comments are
solicited and should be addressed to the two working groups' mailing lists
at issll at mercury.lcs.mit.edu and ietf-ppp at merit.edu and/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-ietf-issll-isslow-mcml-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-issll-isslow-mcml-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-issll-isslow-mcml-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: <19960923110333.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-issll-isslow-mcml-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-issll-isslow-mcml-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960923110333.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28590; 24 Sep 96 10:10 EDT
Received: from localhost by ietf.org id aa27534; 24 Sep 96 10:02 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
cc: vpim-l at ema.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ema-vpim-02.txt
Date: Tue, 24 Sep 1996 10:02:10 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609241002.aa27534 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Voice Profile for Internet Mail - version 2
Author(s) : G. Vaudreuil, G. Parsons
Filename : draft-ema-vpim-02.txt
Pages : 43
Date : 09/23/1996
A class of special-purpose computers has evolved to provide voice messaging
services. These machines generally interface to a telephone switch and
provide call answering and voice messaging services. Traditionally,
messages sent to a non-local machine are transported using analog
networking protocols based on DTMF signaling and analog voice playback.
As the demand for networking increases, there is a need for a standard
high-quality digital protocol to connect these machines. The following
document is a profile of the Internet standard MIME and ESMTP protocols
for use as a digital voice messaging networking protocol.
This profile is based on an earlier effort in the Audio Message Interchange
Specification (AMIS) group to define a voice messaging protocol based on
X.400 technology. This protocol is intended to satisfy the user
requirements statement from that earlier work with the industry standard
ESMTP/MIME mail protocol infrastructures already used within corporate
intranets. This Internet Draft will be referred to as VPIM (Voice Profile
for Internet Mail) in this document. This second version of VPIM is based
on implementation experience and obsoletes RFC 1911 which
describes version 1 of the profile.
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-ema-vpim-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ema-vpim-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-ema-vpim-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: <19960923100050.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ema-vpim-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ema-vpim-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960923100050.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28594; 24 Sep 96 10:10 EDT
Received: from localhost by ietf.org id aa27689; 24 Sep 96 10:04 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ids 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-ids-root-naming-01.txt
Date: Tue, 24 Sep 1996 10:04:02 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609241004.aa27689 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 Integrated Directory
Services Working Group of the IETF.
Title : Managing the X.500 Root Naming Context
Author(s) : D. Chadwick
Filename : draft-ietf-ids-root-naming-01.txt
Pages : 14
Date : 09/23/1996
The X.500 Standard [X.500 93] has the concept of first level DSAs, whose
administrators must collectively manage the root naming context through
bi-lateral agreements or other private means which are outside the scope of
the Standard.
The NameFLOW-Paradise X.500 service has an established
procedure for managing the root naming context, which currently uses Quipu
proprietary replication mechanisms and a root DSA. The benefits that derive
from this are twofold:
- firstly it is much easier to co-ordinate the management of the root
context information, when there is a central point of administration,
- secondly the performance of one-level Search operations is greatly
improved because the Quipu distribution and replication mechanism
does not have a restriction that exists in the 1988 and 1993 Standard.
The NameFLOW-Paradise project is moving towards 1993 ISO Standard
replication protocols and wants to standardise the protocol
and procedure for managing the root naming context which will be based on
1993 Standard protocols. Such a protocol and procedure will be useful to
private X.500 domains as well as to the Internet X.500 public domain.
It is imperative that overall system performance is not degraded
by this transition.
This document describes the use of 1993 ISO Standard protocols for
managing the root context. Whilst the ASN.1 is compatible with
that of the Standard, the actual settings of the parameters are
supplementary to that of the Standard.
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-ids-root-naming-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ids-root-naming-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-ids-root-naming-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: <19960923115422.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ids-root-naming-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ids-root-naming-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960923115422.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28597; 24 Sep 96 10:10 EDT
Received: from localhost by ietf.org id aa27646; 24 Sep 96 10:03 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-otp at bellcore.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-otp-ext-00.txt
Date: Tue, 24 Sep 1996 10:03:18 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609241003.aa27646 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 One Time Password
Authentication Working Group of the IETF.
Title : OTP Extended Responses
Author(s) : C. Metz
Filename : draft-ietf-otp-ext-00.txt
Pages : 11
Date : 09/23/1996
This document provides a specification for a type of response to an OTP
[RFC 1938] challenge that carries explicit indication of the response's
encoding. Codings for the two mandatory OTP data formats using this new
type of response are presented. This document also provides a specification
for a response that allows OTP generator to request that a server
re-initialize a sequence and change parameters such as the secret pass
phrase.
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-otp-ext-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-otp-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-ietf-otp-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: <19960923111831.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-otp-ext-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-otp-ext-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960923111831.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28601; 24 Sep 96 10:10 EDT
Received: from localhost by ietf.org id aa27769; 24 Sep 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-pullen-lame-00.txt
Date: Tue, 24 Sep 1996 10:04:34 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609241004.aa27769 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Limitations of Internet Protocol Suite for Distributed
Simulation in the Large Multicast Environment
Author(s) : M. Pullen, M. Myjak, C. Bouwens
Filename : draft-pullen-lame-00.txt
Pages : 4
Date : 09/23/1996
The characteristics of distributed simulation in the Large Multicast
Environment are described. Mechanics and rates of data exchange are
elaborated. Required network characteristics are described. Using this
information, additional capabilities needed to use the Internet Protocol
Suite for support of large-scale distributed simulation are enumerated.
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-pullen-lame-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-pullen-lame-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-pullen-lame-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: <19960923144911.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-pullen-lame-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-pullen-lame-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960923144911.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28645; 24 Sep 96 10:10 EDT
Received: from localhost by ietf.org id aa27840; 24 Sep 96 10:05 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-yamamoto-wideipv6-comm-model-00.txt
Date: Tue, 24 Sep 1996 10:05:01 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609241005.aa27840 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The IPv6 communication model
Author(s) : K. Yamamoto, A. Onoe, A. Kato
Filename : draft-yamamoto-wideipv6-comm-model-00.txt
Pages : 8
Date : 09/23/1996
This memo discusses semantics of communication with IPv6 addresses. This
model introduces three address scope classes, node-local, site-local, and
global, for both IPv6 unicast and multicast addresses. For a given packet,
all addresses in the packet including those in the routing header must be
in the same address scope class.
Since the sockaddr_in6 address data structure is extended to be able to
hold an interface index number, a kernel and applications can exchange
interface information. A source address is uniquely determined with the
destination address and the outgoing interface.
This memo also clarifies packet processing mechanism for the input,
forward, and output function.
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-yamamoto-wideipv6-comm-model-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-yamamoto-wideipv6-comm-model-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-yamamoto-wideipv6-comm-model-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: <19960923145640.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-yamamoto-wideipv6-comm-model-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-yamamoto-wideipv6-comm-model-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960923145640.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28592; 24 Sep 96 10:10 EDT
Received: from localhost by ietf.org id aa27552; 24 Sep 96 10:02 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-link-negot-00.txt
Date: Tue, 24 Sep 1996 10:02:18 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609241002.aa27552 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 : Proposal for LCP Authentication Option
Author(s) : K. Culbert
Filename : draft-ietf-pppext-link-negot-00.txt
Pages : 7
Date : 09/23/1996
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP is
comprised of three main components: 1. A method for encapsulating
multi-protocol datagrams. 2. A Link Control Protocol (LCP) for
establishing, configuring, and testing the data-link connection.
3. A family of Network Control Protocols (NCPs) for establishing and
configuring different network-layer protocols.
This document defines an interoperable method for the authentication
of peers during the Link negotiation phase.
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-link-negot-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-link-negot-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-link-negot-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: <19960923104825.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-link-negot-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-link-negot-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960923104825.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28828; 24 Sep 96 10:11 EDT
Received: from localhost by ietf.org id aa27950; 24 Sep 96 10:05 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dns-security at tis.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-dnssec-update-02.txt
Date: Tue, 24 Sep 1996 10:05:41 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609241005.aa27950 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 Domain Name System Security
Working Group of the IETF.
Title : Secure Domain Name System Dynamic Update
Author(s) : D. Eastlake
Filename : draft-ietf-dnssec-update-02.txt
Pages : 15
Date : 09/23/1996
Domain Name System (DNS) protocol extensions have been defined to
authenticate the data in DNS and provide key distribution services
(draft-ietf-dnssec-secext-10.txt). DNS Dynamic Update operations have also
been defined (draft-ietf-dnsind-dynDNS-*.txt>, but without a detailed
description of strong security for the update operation. This draft
describes how to use DNS digital signatures covering requests and data to
secure updates and restrict them to those authorized to perform them as
indicated by the updater's possession of cryptographic keys.
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-dnssec-update-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-update-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-dnssec-update-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: <19960923150731.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnssec-update-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnssec-update-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960923150731.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28922; 24 Sep 96 10:11 EDT
Received: from localhost by ietf.org id aa28048; 24 Sep 96 10:06 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-yavatkar-sbm-ethernet-01.txt
Date: Tue, 24 Sep 1996 10:06:14 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609241006.aa28048 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : SBM (Subnet Bandwidth Manager): A Proposal for
Admission Control over Ethernet
Author(s) : R. Yavatkar, D. Hoffman, Y. Bernet, E. Patki
Filename : draft-yavatkar-sbm-ethernet-01.txt
Pages : 14
Date : 09/23/1996
This document outlines an architecture for RSVP-based admission control
over an IEEE 802.3 ethernet environment. The proposed architecture is
designed to work with the current generation of Ethernet infrastructure
(NICs, bridges, hubs, and switches) and should be considered as a first
step towards discovering solutions for implementation of IntServ
capabilities over Ethernet. This draft is intended for discussions in
ISSLL working group's interim meeting (Boston, October 1996) and is a
revision of an earlier draft presented at the Montreal IETF meeting in
June 1996.
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-yavatkar-sbm-ethernet-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-yavatkar-sbm-ethernet-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-yavatkar-sbm-ethernet-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: <19960923144205.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-yavatkar-sbm-ethernet-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-yavatkar-sbm-ethernet-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960923144205.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29314; 24 Sep 96 10:13 EDT
Received: from localhost by ietf.org id aa28117; 24 Sep 96 10:06 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-ghanwani-framework-is-lan-00.txt
Date: Tue, 24 Sep 1996 10:06:41 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609241006.aa28117 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Framework for Providing Integrated Services Over
Shared and Switched LAN Technologies
Author(s) : A. Ghanwani, W. Pace, V. Srinivasan
Filename : draft-ghanwani-framework-is-lan-00.txt
Pages : 6
Date : 09/23/1996
Traditionally, LAN technologies such as ethernet and token ring have been
built to handle best-effort services. There is currently no mechanism for
providing bandwidth or delay guarantees. It is therefore not possible to
provide guaranteed quality of service as will be required by emerging and
future multimedia applications. The anticipated demand for real-time
applications on the Internet has led to the development of RSVP, a
signaling mechanism for performing resource reservation in the Internet.
Concurrently, the Integrated Services working group within the IETF has
been working on the definition of service classes called "Integrated
Services" which are expected to make use of RSVP. Applications will be
designed to use these services in order to obtain the desired QoS from the
network. LAN technologies such as token ring and ethernet typically
constitute the "last hop" in Internet connections. There is therefore a
need to enhance these technologies so that they are able to support these
Integrated Services. In order to enable such services, it necessary to
provide a framework for the deployment of resource management functions.
These functions include the reservation of bandwidth, provision of delay
guarantees, etc. This memo describes a framework for providing the
necessary functionality on shared and switched LAN technologies.
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-ghanwani-framework-is-lan-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ghanwani-framework-is-lan-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-ghanwani-framework-is-lan-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: <19960923142727.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ghanwani-framework-is-lan-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ghanwani-framework-is-lan-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960923142727.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ab29314; 24 Sep 96 10:13 EDT
Received: from localhost by ietf.org id aa28320; 24 Sep 96 10:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: iplpdn at CNRI.Reston.VA.US
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-iplpdn-frmib-dte-08.txt
Date: Tue, 24 Sep 1996 10:07:53 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609241007.aa28320 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 IP Over Large Public Data
Networks Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : Management Information Base for Frame Relay DTEs
Author(s) : C. Brown, F. Baker
Filename : draft-ietf-iplpdn-frmib-dte-08.txt
Pages : 35
Date : 09/23/1996
This memo defines a 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 Frame Relay.
This memo does not specify a standard for the Internet community.
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-iplpdn-frmib-dte-08.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-iplpdn-frmib-dte-08.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-iplpdn-frmib-dte-08.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: <19960923171112.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-iplpdn-frmib-dte-08.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-iplpdn-frmib-dte-08.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960923171112.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02800; 24 Sep 96 10:45 EDT
Received: from localhost by ietf.org id aa02404; 24 Sep 96 10:39 EDT
To: IETF-Announce: ;
Subject: WG ACTION: Uniform Resource Names (urn)
Date: Tue, 24 Sep 1996 10:39:52 -0400
Sender:ietf-announce-request at ietf.org
From: Cynthia Clark <cclark at ietf.org>
Message-ID: <9609241039.aa02404 at ietf.org>
A new working group has been formed in the Applications Area
of the IETF. For additional information, contact the Area Directors or
the WG Chair.
Uniform Resource Names (urn)
----------------------------
Chair(s):
Leslie Daigle <leslie at bunyip.com>
John Curran <jcurran at bbn.com>
Applications Area Director(s):
Keith Moore <moore+iesg at cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand at uninett.no>
Area Advisor
Harald Alvestrand <Harald.T.Alvestrand at uninett.no>
Mailing lists:
General Discussion:urn-ietf at bunyip.com
To Subscribe: majordomo at bunyip.com
In Body: In body of message: subscribe urn-ietf
Archive: ftp://ftp.bunyip.com/pub/mailing-lists/urn-ietf.archive
Description of Working Group:
The goal of this working group is to define both a Uniform Resource
Name (URN) framework and an initial set of components that fit this
framework.
URNs are persistent identifiers for information resources. The output
of this Working Group will comply with RFC 1737, which defines URNs and
gives requirements for them. The framework will define the mechanics
for enabling global scope, persistence, and legacy support requirements
of URNs; requirements for namespaces to support this structure will
also be defined. Although the framework will allow URNs to be defined
that vary in terms of degree of scalability and persistance, ensuring
"user friendliness" of all resultant identifiers is beyond the scope of
this group.
This WG will define the framework for URNs, at least one resolution
registry system, and at least one namespace. RFCs describing
additional material will also be developed (per the milestones,
below).
Input documents:
o A Framework for the Assignment and Resolution of Uniform Resource
Names <draft-daigle-urnframework-00.txt>
o Resolution of Uniform Resource Identifiers using the Domain Name
System <draft-daniel-naptr-01.txt>
o Requirements for URN Resolution Systems
<draft-girod-urn-res-require-00.txt>
Goals and Milestones:
Oct 96 Submit revision of URN Framework document as Internet-Draft.
Oct 96 Submit revised version of the NAPTR proposal as an
Internet-Draft.
Oct 96 Submit Syntax document as an Internet-Draft.
Oct 96 Submit document detailing the N2L/N2R/etc resolution results as
an Internet-Draft.
Nov 96 Submit document describing one (new) namespace as an
Internet-Draft.
Dec 96 Submit paper outlining grandfathering one namespace into the
framework as an Internet-Draft.
Dec 96 Submit revised N2L/N2R/etc document as an Internet-Draft.
Dec 96 Submit NAPTR proposal to IESG as Experimental RFC.
Submit Framework document to IESG for publication as an RFC.
Submit syntax paper to IESG for publication as an RFC.
Feb 97 Submit revised new Namespace document as Internet-Draft.
Feb 97 Submit revised grandfather namespace document as
Internet-Draft.
Feb 97 Submit N2L/N2R/etc document to IESG for publication as RFC.
Mar 97 Submit grandfathered namespace paper to IESG for publication as
RFC.
Submit new namespace proposal to IESG for publication as RFC.
Received: from ietf.org by ietf.org id aa02787; 24 Sep 96 10:45 EDT
Received: from localhost by ietf.org id aa02413; 24 Sep 96 10:39 EDT
To: IETF-Announce: ;
Subject: WG ACTION: IP over Cable Data Network (ipcdn)
Date: Tue, 24 Sep 1996 10:39:56 -0400
Sender:ietf-announce-request at ietf.org
From: Cynthia Clark <cclark at ietf.org>
Message-ID: <9609241039.aa02413 at ietf.org>
A new working group has been formed in the Internet Area
of the IETF. For additional information, contact the Area Directors or
the WG Chair.
IP over Cable Data Network (ipcdn)
----------------------------------
Chair(s):
Masuma Ahmed <mxa at terayon.com>
Mike St. John <stjohns at home.net>
Internet Area Director(s):
Frank Kastenholz <kasten at ftp.com>
Jeffrey Burgan <jburgan at baynetworks.com>
Mailing lists:
General Discussion:ipcdn at terayon.com
To Subscribe: ipcdn-request at terayon.com
Archive: ftp://ftp.terayon.com/pub/ipcdn
Description of Working Group:
The goal of the IPCDN WG is to define how the Internet Protocol (IP) is
to be supported on a Cable Television (CATV) Data Network. The working
group will prepare a framework and requirements document describing a
typical CATV infrastructure and how an IP based network might be
architected to utilize this infrastructure. It will also address the
service interface between IP and the CATV Data Network. The
architecture document will discuss the technical details related to the
differences between symmetric and asymmetric CATV Data Networks. A
terms of reference document will also be published.
Currently, there are no standards available for supporting IP over a
CATV Data Network. The IEEE 802.14 WG is chartered to specify the
physical layer and data link layer protocols for the CATV Data Network.
However, this does not address the issue of mapping higher level
protocols onto the hybrid fiber coax (HFC) access networks. The IPCDN
WG will define a specification of how IP is mapped onto HFC access
networks. Both IPv4 and IPv6 will be addressed, although in separate
documents. The following topics will be discussed:
multicast, broadcast, address mapping and resolution (for IPv4) and
neighbor discovery (for IPv6).
The IPCDN WG will also address issues related to network management,
especially as they concern HFC access networks. It is expected that
other services (i.e. DHCP, RSVP, IPSEC, etc.) will operate unmodified.
Also, depending on the capabilities provided by cable data network
service, specific mappings of RSVP service classes to lower layer
services might be desirable. If additional capabilities become
necessary, these will be directed to the appropriate group.
The IPCDN WG will also keep informed on what other groups in the
industry are doing as it relates to the work of this working group.
The WG is chartered to deliver the following set of documents:
- informational RFCs covering the framework, architecture,
requirements and terms of reference for Cable Data Networks.
- an IPv4-over-HFC access network document covering the mapping
of IP over RF channels, encapsulation and framing of IPv4 packets,
IP to modem and/or PC address resolution, multicast, and broadcast.
- an IPv6-over-HFC access network document covering the mapping
of IP over RF channels , encapsulation and framing of IPv6 packets,
IP to modem and/or PC address resolution, neighbor discovery,
multicast, and broadcast.
- a media-specific mib for managing HFC spectrum.
- a mib for managing cable data network service including
management of IP over cable data network.
Goals and Milestones:
Sep 96 Post Internet-Draft on CATV data network architecture framework
and terminology document.
Sep 96 Post Internet-Draft on IP over CATV data network service (IPC)
document.
Dec 96 Meet at San Jose IETF meeting to review the two Internet-Drafts
and finalize any changes to the architecture framework
document.
Jan 97 Submit the architecture framework I-D to IESG for publication
as an Informational RFC.
Feb 97 Post I-D on the mailing list on the requirements document with
pointers to the IETF standards.
Feb 97 Post I-D on the cable data network MIB/architecture document.
Feb 97 Post I-D on the HFC spectrum management MIB/architecture
document.
Apr 97 Met at Memphis IETF to finalize review of the IP over CATV
requirements, review the document on pointers to the IETF
standards and the MIB/architecture documents.
Apr 97 Begin the WG last call on the IP over CATV I-D.
Aug 97 Finalize review of the requirements document on pointers to the
IETF standards and the MIBs.
Aug 97 Submit the IP over CATV to IESG for publication as an RFC
Aug 97 Begin last call on the requirements document on pointer to the
IETF standards and the MIB documents.
Dec 97 Conclude Working Group.
Received: from ietf.org by ietf.org id aa04623; 24 Sep 96 11:14 EDT
Received: from localhost by ietf.org id aa03954; 24 Sep 96 11:05 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: Protocol Action: The Model Primary Content Type for Multipurpose
Internet Mail Extensions to Proposed Standard
Date: Tue, 24 Sep 1996 11:05:51 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9609241105.aa03954 at ietf.org>
The IESG has approved the Internet-Draft "The Model Primary Content
Type for Multipurpose Internet Mail Extensions"
<draft-nelson-model-mail-ext-05.txt> as a Proposed Standard. The IESG
contact persons are Harald Alvestrand and Keith Moore
Technical Summary
This document extends the top level MIME types (text, image, video,
audio, application, message, multipart) with an eight type called
MODEL, for grouping together things that have some common properties
that distinguish them from the "application" catch-all top level type,
but do not fit into any of the other groups.
Working Group Summary
There has been significant controversy over the idea of new top-level
MIME types, and over this document in previous versions, on the MIME
type registration list (ietf-types at uninett.no).
There is still no consensus on when to register new MIME toplevel
types. The current near silence is probably as much a result of
exhaustion as of total agreement, but there seems consensus that this
proposal is in itself reasonably reasonable.
Protocol Quality
The protocol was reviewed for the IESG by Harald Alvestrand.
Received: from ietf.org by ietf.org id aa05079; 24 Sep 96 11:19 EDT
Received: from localhost by ietf.org id aa04887; 24 Sep 96 11:15 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Definition of X.500 Attribute Types and an Object
Class to Hold Uniform Resource Identifiers (URIs) to Proposed
Standard
Date: Tue, 24 Sep 1996 11:15:30 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9609241115.aa04887 at ietf.org>
The IESG has approved the Internet-Draft "Definition of X.500 Attribute
Types and an Object Class to Hold Uniform Resource Identifiers (URIs)"
<draft-ietf-asid-x500-url-03.txt> as a Proposed Standard. This document
is the product of the Access, Searching and Indexing of Directories
Working Group. The IESG contact persons are Keith Moore and Harald
Alvestrand.
Technical Summary
This specification gives a standard way of placing URLs in the X.500
directory. Since people are doing that today, having one standard way
of doing it is a Good Thing.
Working Group Summary
There was consensus in the WG on this specification.
Protocol Quality
The specification was reviewed for the IESG by Harald Alvestrand.
Received: from ietf.org by ietf.org id aa05462; 24 Sep 96 11:24 EDT
Received: from localhost by ietf.org id aa05185; 24 Sep 96 11:20 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 ietf.org>
Subject: Document Action: IRTF Research Group Guidelines and Procedures to
BCP
Date: Tue, 24 Sep 1996 11:20:01 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9609241120.aa05185 at ietf.org>
The IESG has approved the Internet-Draft "IRTF Research Group
Guidelines and Procedures" <draft-weinrib-irtf-guidelines-00.txt> for
publication as a Best Current Practices RFC. This document is the
product of the Internet Architecture Board (IAB). The coginizant Area
Director is Fred Baker.
Summary
The Internet Research Task Force (IRTF) has responsibility for
organizing groups to investigate research topics related to the
Internet protocols, applications, and technology. IRTF activities
are organized into Research Groups. This document describes the
guidelines and procedures for formation and operation of IRTF
Research Groups. It describes the relationship between IRTF
participants, Research Groups, the Internet Research Steering Group
(IRSG) and the Internet Architecture Board (IAB). The basic duties
of IRTF participants, including the IRTF Chair, Research Group
Chairs and IRSG members are defined.
Working Group Summary
This document describes the current organization and ground rules of
the IRTF, and appears to be faithful to its subject. There has not
been significant disagreement during last call or the IAB
discussions with its description.
Received: from ietf.org by ietf.org id aa05875; 24 Sep 96 11:31 EDT
Received: from localhost by ietf.org id aa05640; 24 Sep 96 11:26 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: pier at isi.edu
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Document Action: Network Renumbering Overview: Why would I want
it and what is it anyway? to Informational
Date: Tue, 24 Sep 1996 11:26:46 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9609241126.aa05640 at ietf.org>
The IESG has reviewed the Internet-Draft "Network Renumbering
Overview: Why would I want it and what is it anyway?"
<draft-ietf-pier-renum-ovrvw-02.txt> and recommends that it be
published by the RFC Editor as an Informational RFC. This document is
the product of the Procedures for Internet/Enterprise Renumbering
Working Group. The IESG contact persons are Scott Bradner and Michael
O'Dell.
Received: from ietf.org by ietf.org id aa27151; 24 Sep 96 16:20 EDT
Received: from localhost by ietf.org id aa26901; 24 Sep 96 16:15 EDT
To: IETF-Announce: ;
Subject: IETF Nominations Committee - Call for Committee Members
Sender:ietf-announce-request at ietf.org
From: Geoff Huston <gih at telstra.net>
Date: Tue, 24 Sep 1996 16:15:32 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9609241615.aa26901 at ietf.org>
(This is a reminder - the relevant date here is 30th September - g)
Once again the IETF Nominations Committee is being formed to fill a
number of positions in the IESG and the IAB which expire in March
1997.
As the chair of this Committee for this year I'm now looking for IETF
volunteers to fill this committee. The workload is not heavy (I
estimate it will entail about 6 teleconference calls and 1 face to face
meeting at the December IETF) and there are two major benefits: you
will be actively participating in one of the more critical functions of
the IETF, and you will be immune from heavy peer pressure to fill one
of the vacant positions!
As with previous years there will be a random selection of names drawn
from the volunteers to populate the committee.
Please respond to me DIRECTLY (gih at telstra.net) _now_ - I'd like to close
this call for volunteers on September 30 1996, and start the
committee's work as of 1 October.
Thanks,
Geoff Huston
97 NomCom Chair
Received: from ietf.org by ietf.org id aa20258; 25 Sep 96 9:34 EDT
Received: from localhost by ietf.org id aa19416; 25 Sep 96 9:24 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-emberson-tftp-multicast-opt-01.txt
Date: Wed, 25 Sep 1996 09:24:26 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609250924.aa19416 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : TFTP Multicast Option
Author(s) : A. Emberson
Filename : draft-emberson-tftp-multicast-opt-01.txt
Pages : 6
Date : 09/24/1996
The Trivial File Transfer Protocol [1] is a simple, lock-step,
file transfer protocol which allows a client to get or
put a file onto a remote host.
This document describes a new TFTP option. This new option will allow
the multiple clients to receive the same file concurrently through
the use of Multicast packets. The TFTP Option Extension mechanism is
described in [2].
Often when similar computers are booting remotely they will each download
the same image file. By adding multicast into the TFTP option
set, two or more computers can download a file concurrently,
thus increasing network efficiency.
This document assumes that the reader is familiar with
the terminology and notation of both [1] and [2].
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-emberson-tftp-multicast-opt-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-emberson-tftp-multicast-opt-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-emberson-tftp-multicast-opt-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: <19960924161218.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-emberson-tftp-multicast-opt-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-emberson-tftp-multicast-opt-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960924161218.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20257; 25 Sep 96 9:34 EDT
Received: from localhost by ietf.org id aa19454; 25 Sep 96 9:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: issll at mercury.lcs.mit.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-issll-atm-support-01.txt, .ps
Date: Wed, 25 Sep 1996 09:25:01 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609250925.aa19454 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 Integrated Services over
Specific Link Layers Working Group of the IETF.
Title : IP Integrated Services with RSVP over ATM
Author(s) : S. Berson, L. Berger
Filename : draft-ietf-issll-atm-support-01.txt, .ps
Pages : 26
Date : 09/24/1996
This draft describes a method for providing IP Integrated Services with
RSVP over ATM switched virtual circuits (SVCs). It provides an overall
approach to the problem as well as a specific method for running over
today's ATM networks. There are two parts of this problem. This draft
provides guidelines for using ATM VCs with QoS as part of an Integrated
Services Internet. A related draft[12] describes service mappings between
IP Integrated Services and ATM services.
Authors' Note
The postscript version of this document contains figures that are not
included in the text version, so it is best to use the postscript version.
Figures will be converted to ASCII in a future 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-issll-atm-support-01.txt".
Or
"get draft-ietf-issll-atm-support-01.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-issll-atm-support-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-issll-atm-support-01.txt".
Or
"FILE /internet-drafts/draft-ietf-issll-atm-support-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: <19960924163227.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-issll-atm-support-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-issll-atm-support-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960924163227.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20243; 25 Sep 96 9:34 EDT
Received: from localhost by ietf.org id aa19360; 25 Sep 96 9:23 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: isdn-mib at cisco.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-isdnmib-dial-control-05.txt
Date: Wed, 25 Sep 1996 09:23:52 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609250923.aa19360 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 ISDN MIB Working Group of
the IETF.
Title : Dial Control Management Information Base
Author(s) : G. Roeck
Filename : draft-ietf-isdnmib-dial-control-05.txt
Pages : 32
Date : 09/24/1996
This draft defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
demand access circuits, including ISDN.
This document specifies a MIB module in a manner that is compliant to the
SNMPv2 SMI. The set of objects is consistent with the SNMP framework and
existing SNMP standards.
This document is a product of the ISDN MIB working group within the Internet
Engineering Task Force. Comments are solicited and should be addressed to
the working group's mailing list at isdn-mib at cisco.com and/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-ietf-isdnmib-dial-control-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-isdnmib-dial-control-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-isdnmib-dial-control-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: <19960924093838.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-isdnmib-dial-control-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-isdnmib-dial-control-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960924093838.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20254; 25 Sep 96 9:34 EDT
Received: from localhost by ietf.org id aa19512; 25 Sep 96 9:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: issll at mercury.lcs.mit.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-issll-atm-mapping-00.txt
Date: Wed, 25 Sep 1996 09:25:15 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609250925.aa19512 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 Integrated Services over
Specific Link Layers Working Group of the IETF.
Title : Interoperation of Controlled-Load and Guaranteed-Service
with ATM
Author(s) : M. Borden, M. Garrett
Filename : draft-ietf-issll-atm-mapping-00.txt
Pages : 25
Date : 09/24/1996
Service mappings are an important aspect of effective interoperation
between Internet Integrated Services and ATM networks. Both Internet and
ATM technologies have well-defined service architectures. In each, a small
number of services are identified, with behavioral descriptions and related
parameters to quantify network traffic and Quality of Service (QoS).
This draft provides mappings between the services of each technology, in
order to facilitate effective end-to-end Quality of Service in the case
where ATM subnetwork technology occurs in the path between Internet end
systems. Specifically, it identifies the types of ATM Virtual Circuits
(VCs) which can be utilized for each of the two currently defined IP
services. A detailed discussion is given of the accompanying parameters
and options, and the interactions between the two models. Some of the text
may be considered preliminary discussion and is expected to be refined as
this draft evolves into a proper specification.
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-issll-atm-mapping-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-issll-atm-mapping-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-issll-atm-mapping-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: <19960924165620.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-issll-atm-mapping-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-issll-atm-mapping-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960924165620.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20252; 25 Sep 96 9:34 EDT
Received: from localhost by ietf.org id aa19398; 25 Sep 96 9:24 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: idmr at cs.ucl.ac.uk
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-idmr-cbt-spec-06.txt
Date: Wed, 25 Sep 1996 09:24:07 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609250924.aa19398 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 Inter-Domain Multicast
Routing Working Group of the IETF.
Title : Core Based Trees (CBT) Multicast -- Protocol
Specification --
Author(s) : A. Ballardie, S. Reeve, N. Jain
Filename : draft-ietf-idmr-cbt-spec-06.txt
Pages : 44
Date : 09/24/1996
This document describes the Core Based Tree (CBT) network layer multicast
protocol. CBT is a next-generation multicast protocol that makes use of a
shared delivery tree rather than separate per-sender trees utilized by most
other multicast schemes [1, 2, 3]. The CBT architecture is described in
[4a].
This specification includes an optimization whereby unencapsulated (native)
IP-style multicasts are forwarded by CBT routers, resulting in very good
forwarding performance. This mode of operation is called CBT "native
mode". Native mode can only be used in CBT-only domains (footnote 1).
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-idmr-cbt-spec-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt-spec-06.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-idmr-cbt-spec-06.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: <19960924112726.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-idmr-cbt-spec-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idmr-cbt-spec-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960924112726.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20249; 25 Sep 96 9:34 EDT
Received: from localhost by ietf.org id aa19381; 25 Sep 96 9:24 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: isdn-mib at cisco.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-isdnmib-snmp-isdn-mib-08.txt
Date: Wed, 25 Sep 1996 09:24:02 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609250924.aa19381 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 ISDN MIB Working Group of
the IETF.
Title : ISDN Management Information Base
Author(s) : G. Roeck
Filename : draft-ietf-isdnmib-snmp-isdn-mib-08.txt
Pages : 48
Date : 09/24/1996
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it defines a minimal set of managed objects for
SNMP-based management of ISDN terminal interfaces. ISDN interfaces are
supported on a variety of equipment (for data and voice) including terminal
adapters, bridges, hosts, and routers.
This document specifies a MIB module in a manner that is compliant
to the SNMPv2 SMI. The set of objects is consistent with the
SNMP framework and existing SNMP standards.
This document is a product of the ISDN MIB working group within the Internet
Engineering Task Force. Comments are solicited and should be addressed to
the working group's mailing list at isdn-mib at cisco.com and/or the author.
The current version of this document reflects changes made during the last
call period and the IESG review.
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-isdnmib-snmp-isdn-mib-08.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-isdnmib-snmp-isdn-mib-08.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-isdnmib-snmp-isdn-mib-08.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: <19960924110840.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-isdnmib-snmp-isdn-mib-08.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-isdnmib-snmp-isdn-mib-08.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960924110840.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20256; 25 Sep 96 9:34 EDT
Received: from localhost by ietf.org id aa19529; 25 Sep 96 9:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: tosi at lkg.dec.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-pouffary-itot-03.txt
Date: Wed, 25 Sep 1996 09:25:21 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609250925.aa19529 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : ISO Transport Service on top of TCP (ITOT)
Author(s) : Y. Pouffary, A. Young
Filename : draft-pouffary-itot-03.txt
Pages : 28
Date : 09/25/1996
This document is a revision to RFC1006 written by Marshall T. Rose and
Dwight E. Cass. Since the release of RFC1006 in May 1987, much experience
has been gained in using ISO transport services on top of TCP. This
document refines the protocol and supersedes RFC1006.
This document describes the mechanism to allow ISO Transport Services to
run over TCP over IPv4 or IPv6. It also defines a number of new features,
which are not provided in RFC1006.
The goal of this version is to minimise the number of changes to RFC1006
and ISO 8073 transport protocol definitions, while maximising performance,
extending its applicability and protecting the installed base of
RFC1006 users.
Discussion list: tosi at lkg.dec.com
To Subscribe send mail to tosi-request at lkg.dec.com
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-pouffary-itot-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-pouffary-itot-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-pouffary-itot-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: <19960925091208.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-pouffary-itot-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-pouffary-itot-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960925091208.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20709; 25 Sep 96 9:38 EDT
Received: from localhost by ietf.org id aa20497; 25 Sep 96 9:35 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-cid-01.txt
Date: Wed, 25 Sep 1996 09:35:19 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609250935.aa20497 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 : Content-ID and Message-ID Uniform Resource Locators
Author(s) : E. Levinson
Filename : draft-ietf-mhtml-cid-01.txt
Pages : 5
Date : 09/24/1996
The Uniform Resource Locator (URL) schemes, "cid:"; and "mid:"; allow the
content of Text/HTML or other MIME media types to contain references to
other body parts in the same or a different message.
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-cid-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mhtml-cid-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-cid-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: <19960925093429.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mhtml-cid-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mhtml-cid-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960925093429.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa23867; 25 Sep 96 10:39 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18894;
25 Sep 96 10:39 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <NAA08145 at pad-thai.cam.ov.com>; Wed, 25 Sep 1996 13:59:01 GMT
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA22121; Wed, 25 Sep 96 09:59:00 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <NAA08137 at pad-thai.cam.ov.com>; Wed, 25 Sep 1996 13:58:59 GMT
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id JAA00313; Wed, 25 Sep 1996 09:58:58 -0400
Message-Id: <199609251358.JAA00313 at winkl.cam.ov.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: agenda topics solicited; GSS-V2 C bindings focus and goal
Date: Wed, 25 Sep 1996 09:58:57 -0400
From: John Linn <linn at cam.ov.com>
CAT fanciers:
(1) It's that time again... Does anyone have topics for which they'd
like to request presentation or discussion time within the CAT WG
agenda for the San Jose IETF meeting (week of 9 December)?
(2) The list has been silent on the Process Issues section of my 13
September message re GSS-V2 status, and draft-ietf-cat-gssv2-08.txt is
enroute to proceed to Proposed Standard per IESG approval. I believe
that the focus of GSS-V2 discussion should now emphasize convergence
on the C bindings document via specifically agreed changes relative to
draft-ietf-cat-gssv2-cbind-02.txt. As a goal, I believe we should
seek to complete this convergence no later than the December IETF
meeting. While it would be desirable for this discussion to proceed
in a manner which does not impact the high-level
Proposed-Standard-to-be, this is not an absolute constraint. If
changes to the high-level specification are agreed to be necessary,
they can be recorded in working Internet-Drafts and reflected in a
subsequent revision to the high-level document when advancement to
Draft Standard is targeted (which, I believe, we should envision as
involving both a high-level and bindings document, alongside one
another and with corresponding implementations).
--jl
Received: from ietf.org by ietf.org id aa25003; 26 Sep 96 4:44 EDT
Received: from cnri by ietf.org id aa24765; 26 Sep 96 4:35 EDT
Received: from einstein.technet.sg by CNRI.Reston.VA.US id aa06785;
26 Sep 96 4:35 EDT
Received: from stcs.com.sg (mailhost.scs.com.sg [192.245.59.187]) by einstein.technet.sg (8.7.6/8.7.3) with SMTP id QAA04221 for <ietf at cnri.reston.va.us>; Thu, 26 Sep 1996 16:34:22 +0800 (SGT)
Received: from scscc1.scsnet.scs.com.sg by stcs.com.sg (5.0/SMI-SVR4)
id AA10439; Thu, 26 Sep 96 16:29:48 SST
Received: by scscc1.scsnet.scs.com.sg with Microsoft Mail
id <324B12ED at scscc1.scsnet.scs.com.sg>; Thu, 26 Sep 96 16:34:05 PDT
Sender:ietf-request at ietf.org
From: "Neo Kok Beng, SlsMgr,STCS/BMDU" <neokb at scscc1.scsnet.stcs.com.sg>
To: 'IETF ' <ietf at CNRI.Reston.VA.US>
Subject: Please unsubscribe. Thanks
Date: Thu, 26 Sep 96 16:22:00 PDT
Message-Id: <324B12ED at scscc1.scsnet.scs.com.sg>
Encoding: 2 TEXT
X-Mailer: Microsoft Mail V3.0
Source-Info: From (or Sender) name not authenticated.
neokb at scscc1.scsnet,scs.com.sg
Received: from ietf.org by ietf.org id aa28082; 26 Sep 96 8:17 EDT
Received: from cnri by ietf.org id aa28008; 26 Sep 96 8:13 EDT
Received: from panda.ioz.ac.cn by CNRI.Reston.VA.US id aa16083;
26 Sep 96 8:13 EDT
Received: by panda.ioz.ac.cn; (5.65/1.1.8.2/27May96-1015AM)
id AA29889; Thu, 26 Sep 1996 20:13:16 +0800
Date: Thu, 26 Sep 1996 20:13:15 +0800 (CST)
Sender:ietf-request at ietf.org
From: SEA <sea at panda.ioz.ac.cn>
To: 'IETF' <ietf at CNRI.Reston.VA.US>
Subject: Please unsubscribe. Thanks (fwd)
Message-Id: <Pine.OSF.3.91.960926201159.29883A-100000 at panda.ioz.ac.cn>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
sea at panda.ioz.ac.cn
Received: from ietf.org by ietf.org id aa29608; 26 Sep 96 8:47 EDT
Received: from cnri by ietf.org id aa29528; 26 Sep 96 8:43 EDT
Received: from relay.pwj.com by CNRI.Reston.VA.US id aa03968; 26 Sep 96 8:43 EDT
Received: by relay.pwj.com; id IAA17112; Thu, 26 Sep 1996 08:43:20 -0400
Received: from blanca.lnh.pwj.com(162.66.92.36) by relay.pwj.com via smap (V3.1)
id xma017095; Thu, 26 Sep 96 08:43:01 -0400
Received: from jlenn (Jason-Lenn.lnh.pwj.com [162.66.101.6]) by blanca.lnh.pwj.com (8.7.1/8.7.1) with SMTP id IAA11760 for <ietf at CNRI.Reston.VA.US>; Thu, 26 Sep 1996 08:43:00 -0400 (EDT)
Sender:ietf-request at ietf.org
From: Jason Lenn <jlenn at painewebber.com>
Message-Id: <960926084208.ZM14622 at jlenn>
Date: Thu, 26 Sep 1996 08:42:06 -0400
X-Mailer: Z-Mail 4.0 (4.0.0 Aug 21 1995)
To: ietf at CNRI.Reston.VA.US
Subject: Please unsubscribe
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
thanks!
jlenn
--
********************************************************************
Jason Lenn
Assistant Vice President
Distributed Systems Management
PaineWebber
800 Harbor Blvd
Weehawken, NJ 07087
Office 201-902-4320
Pager 800-759-8888 Pin 1201341
Email jlenn at painewebber.com
*********************************************************************
Received: from ietf.org by ietf.org id aa02586; 26 Sep 96 9:48 EDT
Received: from localhost by ietf.org id aa01793; 26 Sep 96 9:36 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: pier at isi.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-pier-subnet-lists-00.txt
Date: Thu, 26 Sep 1996 09:36:02 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609260936.aa01793 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 Procedures for
Internet/Enterprise Renumbering Working Group of the IETF.
Title : Subnet Lists
Author(s) : P. Nesser
Filename : draft-ietf-pier-subnet-lists-00.txt
Pages : 34
Date : 09/25/1996
This document enumerates the scheme of choosing subnets by most significant
bit (msb) of the host portion of the address as described in RFC 1219. Two
tables provide the specific information for class B (/16) networks and
class C (/24) networks. It is intended to aid network planners in adopting
an addressing allocation scheme which is "renumbering friendly."
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-pier-subnet-lists-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pier-subnet-lists-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-pier-subnet-lists-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: <19960926093528.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pier-subnet-lists-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pier-subnet-lists-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960926093528.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02585; 26 Sep 96 9:48 EDT
Received: from localhost by ietf.org id aa01810; 26 Sep 96 9:36 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-bolton-edimib-00.txt, .ps
Date: Thu, 26 Sep 1996 09:36:08 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609260936.aa01810 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Electronic Data Interchange MIB (EDIMIB) Version 1
Author(s) : J. Andrukonis, D. Bolton
Filename : draft-bolton-edimib-00.txt, .ps
Pages : 10
Date : 09/25/1996
This memo defines a MIB for use with managing EDI systems. The term EDI
systems includes large scale systems providing translator functions such as
the US federal government's Electronic Commerce Processing Node (ECPN) for
which this MIB was specifically designed, as well as smaller Value Added
Network (VAN) systems. Because of the desire for scalability variable
names are deliberately vague, so that a channel may represent a single
user, a group of users that use the same network entry point or that are
defined by the implementor as functionally similar, or (as in the case of
the ECPN) a connection to a third party network. This MIB does not address
management of client systems which connect to the various EDI systems.
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-bolton-edimib-00.txt".
Or
"get draft-bolton-edimib-00.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-bolton-edimib-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-bolton-edimib-00.txt".
Or
"FILE /internet-drafts/draft-bolton-edimib-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: <19960925152135.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-bolton-edimib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-bolton-edimib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960925152135.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02588; 26 Sep 96 9:48 EDT
Received: from localhost by ietf.org id aa01827; 26 Sep 96 9:36 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ids 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-ids-inp-00.txt
Date: Thu, 26 Sep 1996 09:36:14 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609260936.aa01827 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 Integrated Directory
Services Working Group of the IETF.
Title : Internet Nomenclator Project
Author(s) : J. Ordille
Filename : draft-ietf-ids-inp-00.txt
Pages : 14
Date : 09/25/1996
The goal of the Internet Nomenclator Project is to integrate the hundreds
of publicly available CCSO servers from around the world. Each CCSO server
has a database schema that is tailored to the needs of the organization
that owns it. The project is integrating the different database schema
into one query service. The Internet Nomenclator Project will provide fast
cross-server searches for locating people on the Internet. It augments
existing CCSO services by supplying schema integration, more extensive
indexing, and two kinds of caching -- all this in a system that scales as
the number of CCSO servers grows. One of the best things about the system
is that administrators can incorporate their CCSO servers into Nomenclator
without changing the servers. All Nomenclator needs is basic information
about the server.
This document provides an overview of the Nomenclator system, describes
how to register a CCSO server in the Internet Nomenclator Project, and
how to use the Nomenclator search engine to find people on the Internet.
Distribution of this document is unlimited. Comments should be sent
to 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-ietf-ids-inp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ids-inp-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-ids-inp-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: <19960925113457.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ids-inp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ids-inp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960925113457.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03229; 26 Sep 96 9:51 EDT
Received: from localhost by ietf.org id aa02605; 26 Sep 96 9:47 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-suzuki-st2-over-atm-00.txt
Date: Thu, 26 Sep 1996 09:47:09 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9609260947.aa02605 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : ST2+ over ATM Protocol Specification - UNI 3.1 Version
Author(s) : M. Suzuki
Filename : draft-suzuki-st2-over-atm-00.txt
Pages : 28
Date : 09/18/1996
This document specifies an ATM-based protocol for communication between
ST2+ agents. The ST2+ over ATM protocol supports the matching of one hop in
an ST2+ tree-structure stream with one ATM connection. In this document,
ATM is a subnet technology for the ST2+ stream.
The ST2+ over ATM protocol is designed to achieve resource-reservation
communications across ATM and non-ATM networks, to extend the UNI 3.1/4.0
signaling functions, and to reduce the UNI 4.0 LIJ signaling limitations.
The specifications of the ST2+ over ATM protocol consist of a revision of
RFC 1819 ST2+ and specifications of protocol interaction between ST2+ and
ATM on the user plane, management plane, and control plane which correspond
to the three planes of the B-ISDN protocol reference model.
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-suzuki-st2-over-atm-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-suzuki-st2-over-atm-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-suzuki-st2-over-atm-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: <19960919093643.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-suzuki-st2-over-atm-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-suzuki-st2-over-atm-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960919093643.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18134; 26 Sep 96 17:31 EDT
Received: from lightstream.cisco.com by ietf.org id aa17886; 26 Sep 96 17:23 EDT
Received: from cisco.com (bdavie-sun.cisco.com [171.69.208.20]) by lightstream.cisco.com (8.6.11/8.6.11) with ESMTP id RAA08634; Thu, 26 Sep 1996 17:22:15 -0400
Received: from localhost (bdavie at localhost) by cisco.com (8.6.11/8.6.11) with SMTP id RAA08904; Thu, 26 Sep 1996 17:22:18 -0400
Message-Id: <199609262122.RAA08904 at cisco.com>
X-Authentication-Warning: bdavie-sun.cisco.com: Host localhost didn't use HELO protocol
To: ietf at ietf.org, ion at nexen.com
Subject: Tag Switching Discussion Mailing List
Date: Thu, 26 Sep 1996 17:22:17 -0400
Sender:ietf-request at ietf.org
From: Bruce Davie <bdavie at cisco.com>
Source-Info: From (or Sender) name not authenticated.
All parties interested in discussion on the subject of tag switching
are invited to join the mailing list `tagswitch at cisco.com' by sending
a message to `tagswitch-request at cisco.com'. Mail will be archived at
ftp://ftp.cisco.com/ftp/tagswitch.
It is our goal to have a BOF on this subject at the next IETF meeting.
Reading the relevant internet drafts prior to posting to the
list is recommended. Two drafts have been posted in the usual IETF
directories:
draft-rfced-info-rekhter-00.txt
draft-doolan-tdp-spec-00.txt
Bruce Davie
bsd at cisco.com
Received: from ietf.org by ietf.org id aa19004; 26 Sep 96 17:54 EDT
Received: from netcom20.netcom.com by ietf.org id aa18926; 26 Sep 96 17:52 EDT
Received: (from samg at localhost) by netcom20.netcom.com (8.6.13/Netcom)
id OAA20637; Thu, 26 Sep 1996 14:51:45 -0700
Sender:ietf-request at ietf.org
From: Sam Ghandchi <samg at netcom.com>
Message-Id: <199609262151.OAA20637 at netcom20.netcom.com>
Subject: Hi
To: ietf at ietf.org
Date: Thu, 26 Sep 1996 14:51:45 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 15
Source-Info: From (or Sender) name not authenticated.
subscribe ietf
Received: from cnri by ietf.org id aa21659; 26 Sep 96 19:31 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa02917;
26 Sep 96 19:31 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <WAA14946 at pad-thai.cam.ov.com>; Thu, 26 Sep 1996 22:45:27 GMT
Received: from ingwwdf.sap-ag.de by MIT.EDU with SMTP
id AA18301; Thu, 26 Sep 96 18:45:25 EDT
Received: from sap-ag.de (sapwdf.wdf.sap-ag.de [147.204.3.3]) by ingwwdf.wdf.sap-ag.de (8.6.12/8.6.9) with SMTP id AAA01769 for <cat-ietf at mit.edu>; Fri, 27 Sep 1996 00:27:26 +0200
Received: from hw1464.wdf.sap-ag.de by sap-ag.de with SMTP id AA08405
(5.67b8/IDA-1.5 for <cat-ietf at mit.edu>); Fri, 27 Sep 1996 00:27:50 +0200
Message-Id: <199609262227.AA08405 at sap-ag.de>
Received: by hw1464.wdf.sap-ag.de
(1.39.111.2/16.2) id AA278246867; Fri, 27 Sep 1996 00:27:47 +0200
From: Martin Rex <martin.rex at sap-ag.de>
Subject: gss_context_time()==CREDENTIALS_EXPIRED
To: cat-ietf at mit.edu
Date: Fri, 27 Sep 1996 00:27:46 +0200 (MESZ)
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
What was the rationale for gss_context_time() returning
the major status GSS_S_CREDENTIALS_EXPIRED ?
I would assume that it is completely a local/implementation issue if
a mechanism keeps a copy of the credentials around, that were used to
establish the security context. I release_cred() the application-visible
credentials immediately when init_sec_context() and accept_sec_context()
return GSS_S_COMPLETE, and I don't care what the mechanism does with
the credentials internally. Therefore the GSS_S_CREDENTIALS_EXPIRED
return code is kind of useless for me. I'm worring only about the
context lifetime at this point. (Reason: I'm transferring security
contexts between different processes, and gss_cred_t objects are
not transferable -- in my case, it would also be unnecessary burden
to carry credentials around).
I'm about to implement a security context refresh at the application
level and wanted to use gss_context_time() prior to gss_wrap()/gss_getmic()
to check if there is enough time left so that the data can be transferred
and unwrapped at the other end before context expiration. I will use^
a configurable threshold (default ~10-15 minutes), because I won't be able
to handle security context expiration gracefully for the receiver (i.e.
CONTEXT_EXPIRED returned from gss_unwrap() or gss_verifymic()).
Oooops! I've just grep'ed the GSSAPI specifications again and noticed
that GSS_S_CREDENTIALS_EXPIRED is also a valid return value for the
the message protection calls (wrap/unwrap/getmic/verifymic)?!
This error code is not present in newer v2 calls like gss_wrap_size_limit,
gss_export_context, gss_import_context and gss_inquire_context.
This looks somewhat inconsistent.
I don't think that GSS-API does or should mandate for all mechanisms
that the security context lifetime should be limited by the lifetime of
the credentials that were used to establish this context. I know that
the Kerberos 5 gssapi mechanism does this, but at that level it already
is a local/implementation issue.
Personally I'd like to see the return code GSS_S_CREDENTIALS_EXPIRED
being deprecated for all calls that do not reference credentials
context_time/wrap/unwrap/getmic/verifymic for GSSAPI v2 and I would
appreciate a hint for implementors how it was intended to be used and
how it is used in V1, and how it SHOULD NOT be used...
-Martin
Received: from ietf.org by ietf.org id aa08132; 27 Sep 96 10:00 EDT
Received: from localhost by ietf.org id aa07492; 27 Sep 96 9:38 EDT
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: The PPP Bandwidth Allocation Protocol (BAP) & Bandwidth
Allocation Control Protocol (BACP) to Proposed Standard
Reply-to: iesg at ietf.org
Date: Fri, 27 Sep 1996 09:38:56 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9609270938.aa07492 at ietf.org>
The IESG has received a request from the Point-to-Point Protocol
Extensions Working Group to consider "The PPP Bandwidth Allocation
Protocol (BAP) - The PPP Bandwidth Allocation Control Protocol (BACP)"
<draft-ietf-pppext-bacp-04.txt> for the status of Proposed 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 October 10, 1996.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa13615; 27 Sep 96 13:43 EDT
Received: from cnri by ietf.org id aa13254; 27 Sep 96 13:36 EDT
Received: from [128.9.0.32] by CNRI.Reston.VA.US id aa26977; 27 Sep 96 13:36 EDT
Received: from europe.std.com by venera.isi.edu (5.65c/5.61+local-25)
id <AA11824>; Fri, 27 Sep 1996 10:36:13 -0700
Received: from world.std.com by europe.std.com (8.7.5/BZS-8-1.0)
id NAA26874; Fri, 27 Sep 1996 13:34:49 -0400 (EDT)
Received: from localhost by world.std.com (5.65c/Spike-2.0)
id AA07174; Fri, 27 Sep 1996 13:34:48 -0400
Date: Fri, 27 Sep 1996 13:34:48 -0400 (EDT)
Sender:ietf-request at ietf.org
From: Robert E Lamm <cync at world.std.com>
To: announcements.chi at xerox.com, arl at arl.wustl.edu, atm at bbn.com,
ccrc at dworkin.wustl.edu, cgs at mit.edu, cip at bbn.com,
end2end-interest at isi.edu, ftroup at aurora.cis.upenn.edu,
gtroup at dworkin.wustl.edu, icad-request at santafe.edu, ietf at isi.edu,
iplpdn at CNRI.Reston.VA.US, ir-l%uccvma.bitnet at cunyvm.cuny.edu,
klaus at informatik.rwth.aachen.de, rem-conf-request at es.net,
s-comput at tcsvm.bitnet, sig11 at roses.stanford.edu, sigmedia at bellcore.com,
simon at cui.unige.ch, sip-request at catarina.usc.edu, smds at CNRI.Reston.VA.US,
sound at acm.org, tccc at cs.umb.edu, tcplw at cray.com,
tf-mm at i4serv.informatik.rwth.aachen.de, uist.chi at xerox.com,
wittig at vnet.ibm.com
Cc: Multimedia '96 Organizers <MM96EX at listserv.acm.org>
Subject: ACM Multimedia '96
Message-Id: <Pine.SGI.3.93.960927133303.13126B-100000 at world.std.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
ACM Multimedia '96
Boston, Massachusetts
November 18-22, 1996
**************
Register Now!
**************
Visit
http://www.acm.org/sigmm/MM96/
or
http://www.informatik.uni-mannheim.de/pi4/MM96/
for complete conference information.
Philippe Aigrain and V. Michael Bove, Jr., General Chairs
Wendy Hall and Tom Little, Program Chairs
Received: from cnri by ietf.org id aa15407; 27 Sep 96 14:55 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12060;
27 Sep 96 14:55 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <SAA20908 at pad-thai.cam.ov.com>; Fri, 27 Sep 1996 18:24:07 GMT
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA26806; Fri, 27 Sep 96 14:24:05 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA24318; Fri, 27 Sep 1996 14:24:04 -0400
Date: Fri, 27 Sep 1996 14:24:04 -0400
Message-Id: <9609271824.AA24318 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: John Linn <linn at cam.ov.com>
Cc: cat-ietf at mit.edu, linn at cam.ov.com
In-Reply-To: John Linn's message of Wed, 25 Sep 1996 09:58:57 -0400,
BAD MSG:
<199609251358.JAA00313 at winkl.cam.ov.com>
ubject: Re: agenda topics solicited; GSS-V2 C bindings focus and goal
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Cc: linn at cam.ov.com
Date: Wed, 25 Sep 1996 09:58:57 -0400
(2) The list has been silent on the Process Issues section of my 13
September message re GSS-V2 status, and draft-ietf-cat-gssv2-08.txt is
enroute to proceed to Proposed Standard per IESG approval. I believe
that the focus of GSS-V2 discussion should now emphasize convergence
on the C bindings document via specifically agreed changes relative to
draft-ietf-cat-gssv2-cbind-02.txt.
Agreed.
- Ted
Received: from cnri by ietf.org id aa15414; 27 Sep 96 14:55 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12114;
27 Sep 96 14:55 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <SAA20744 at pad-thai.cam.ov.com>; Fri, 27 Sep 1996 18:15:52 GMT
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA25023; Fri, 27 Sep 96 14:15:32 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA24306; Fri, 27 Sep 1996 14:15:20 -0400
Date: Fri, 27 Sep 1996 14:15:20 -0400
Message-Id: <9609271815.AA24306 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Martin.Rex at sap-ag.de
Cc: cat-ietf at mit.edu
In-Reply-To: Martin Rex's message of Fri, 27 Sep 1996 00:27:46 +0200 (MESZ),
BAD MSG:
<199609262227.AA08405 at sap-ag.de>
ubject: Re: gss_context_time()==CREDENTIALS_EXPIRED
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
From: Martin Rex <martin.rex at sap-ag.de>
Date: Fri, 27 Sep 1996 00:27:46 +0200 (MESZ)
Personally I'd like to see the return code GSS_S_CREDENTIALS_EXPIRED
being deprecated for all calls that do not reference credentials
context_time/wrap/unwrap/getmic/verifymic for GSSAPI v2 and I would
appreciate a hint for implementors how it was intended to be used and
how it is used in V1, and how it SHOULD NOT be used...
Agreed. All aside from the question of whether or not contexts should
expire when the credentials do (which we have settled, although
personally I would preferred if we had settled it the other way), there
is a GSS_S_CONTEXT_EXPIRED error code, and there's no reason for
gss_wrap/unwrap/etc. to return GSS_S_CREDENTIALS_EXPIRED.
- Ted
Received: from ietf.org by ietf.org id aa15891; 27 Sep 96 15:20 EDT
Received: from cnri by ietf.org id aa15700; 27 Sep 96 15:13 EDT
Received: from [128.9.0.32] by CNRI.Reston.VA.US id aa22539; 27 Sep 96 15:13 EDT
Received: from dworkin.wustl.edu by venera.isi.edu (5.65c/5.61+local-25)
id <AA15754>; Fri, 27 Sep 1996 12:13:12 -0700
Received: (from milind at localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA26198; Fri, 27 Sep 1996 14:03:35 -0500
Date: Fri, 27 Sep 1996 14:03:35 -0500
Sender:ietf-request at ietf.org
From: "Milind M. Buddhikot" <milind at dworkin.wustl.edu>
Message-Id: <199609271903.OAA26198 at dworkin.wustl.edu>
To: announcements.chi at xerox.com, arl at arl.wustl.edu, atm at bbn.com,
ccrc at dworkin.wustl.edu, cgs at mit.edu, cip at bbn.com,
end2end-interest at isi.edu, ftroup at aurora.cis.upenn.edu,
gtroup at dworkin.wustl.edu, icad-request at santafe.edu, ietf at isi.edu,
iplpdn at CNRI.Reston.VA.US, ir-l%uccvma.bitnet at cunyvm.cuny.edu,
klaus at informatik.rwth.aachen.de, rem-conf-request at es.net,
s-comput%tcsvm.BITNET at wugate.wustl.edu, sig11 at roses.stanford.edu,
sigmedia at bellcore.com, simon at cui.unige.ch, sip-request at catarina.usc.edu,
smds at CNRI.Reston.VA.US, sound at acm.org, tccc at cs.umb.edu, tcplw at cray.com,
tf-mm at i4serv.informatik.rwth.aachen.de, uist.chi at xerox.com,
wittig at vnet.ibm.com
Subject: Call-For-Papers (CFP) for NOSSDAV97
Source-Info: From (or Sender) name not authenticated.
Hi:
Enclosed please find a Call-for-Papers (CFP) for the 7th International
Workshop on Network and Operating Systems Support for Digital Audio
and Video to be held in St. Louis, Missouri (USA) from May 19-21,
1997.
Please feel free to circulate the CFP by any means you deem
appropriate. Also, please excuse any multiple copies of this CFP you
may receive due to your memberships in multiple mailing lists.
Thanks and regards.
Milind
*****************************************************************************
* *
* NOSSDAV'97 *
* *
* Call-for-Papers *
* *
* *
* The 7th International Workshop on Network and Operating System *
* Support for Digital Audio and Video (NOSSDAV 97) *
* *
* URL: http://www.arl.wustl.edu/NOSSDAV97/nossdav.html *
* *
* May 19 - 21 1997 *
* *
* Hosted by: *
* The Applied Research Laboratory *
* Department of Computer Science *
* Washington University in St. Louis, Missouri *
* *
* IEEE Sponsorship and ACM Cooperation under consideration. *
******************************************************************************
Objectives
The 7th International Workshop on Network and Operating Systems
Support for Digital Audio and Video (NOSSDAV 97) is the international
workshop concerned with state of the art technology in networking and
operating system support for multimedia systems. For seven years,
NOSSDAV has proven to be an outstanding forum for researchers involved
in building innovative multimedia systems, networks and applications
on both the research and industrial front. Other topics that will be
examined include "middleware" for multimedia, media toolkits, mobile
communications, Virtual Reality (VR), real-time systems, software
agents, digital libraries, and other digital media besides audio and
video.
A key aspect of the workshop is that it provides extensive discussion
periods during which attendees can informally discuss their current
work and future research directions. Traditionally, NOSSDAV has
emphasized on high quality experimental research that prototypes
systems to explore innovative solutions to the problems in the diverse
areas of multimedia computing. NOSSDAV97 will continue this tradition.
Relevant topics for the workshop include:
* APIs and Continuous Media (CM) programming abstractions for
multimedia
* Cell-based system architectures
* Communication protocols for multimedia
* Distributed multimedia systems
* End-to-end admission control
* High-speed/ATM networks
* Micro-kernel and OS support for real-time communications
* Mobile multimedia systems
* Multicast protocols and media scaling
* Multimedia network interfaces
* Multimedia-oriented desk, local and wide area networks
* Multimedia and the Internet
* Multimedia storage, server, and I/O architectures
* Quality of service and synchronization frameworks
* Resource management and reservation in the OS and network
* Software agents for multimedia systems
* TV set-top device communication
* VOD system architecture
* VR systems
* Workstation and PDA architectures for multimedia
Submissions
Two types of submissions are solicited: position papers and research
papers. For the purpose of paper review, position papers are
restricted to three single-spaced ASCII pages. Research papers are
restricted to an extended abstract no longer than five formatted
postscript pages. Papers should be electronically mailed to
NOSSDAV97 at arl.wustl.edu. Only if electronic submission is impossible,
papers may be sent to the following mailing address.
Dr. Gurudatta M. Parulkar
ATTN: NOSSDAV 97
Washington University
Department of Computer Science
Applied Research Laboratory
Campus Box 1045
St. Louis, Missouri 63130
USA
Please note that the proceedings of the workshop will be published as
a book by Springer-Verlag and the best papers will be forwarded to
selected journals for publication.
Important Dates
Submission Deadline: 15 January 1997 (A FIRM DEADLINE)
Acceptance Notification: 15 March 1997
Final Paper Due: 15 April 1997 (A FIRM DEADLINE)
Workshop: 19 - 21 May 1997
Program Chair
Dr. Gurudatta M. Parulkar
Director, Applied Research Lab
Department of Computer Science
Washington University, St. Louis MO. USA
guru at arl.wustl.edu, TEL: (314) 935-7534
Local Arrangements Chair
John D. DeHart
Senior Research Associate, Applied Research Lab
Department of Computer Science
Washington University, St. Louis MO. USA
jdd at arl.wustl.edu, TEL: (314) 935-7534
Other Correspondance:
NOSSDAV97 at arl.wustl.edu TEL: (314) 935-7534
Program Committee
(To be edited at future date)
Andrew T. Campbell, Columbia University
Domenico Ferrari, Universita` Cattolica, Italy
Kevin Jeffay, Univ of North Carolina
Mike Jones, Microsoft, Inc.
Chuck Kalmanek, AT&T Research
S. Keshav, Cornell University
Jim Kurose, University of Masachusetts
Monica Lam, Stanford University
Ian Leslie, Cambridge University, UK
Tom Little, Boston University
Derek McAuley, University of Glasgow, UK
Steve McCanne, Univ of California, Berkeley
Gerald Neufeld, Univ of British Columbia, Canada
Duane Northcutt, Sun Microsystems
Joe Pasquale, Univ of California, San Diego
Bernhard Plattner, ETH, Zurich
Steve Pink, SICS, Sweden
P Venkat Rangan, Univ of California, San Diego
KK Ramakrishnan, AT&T Research
Henning Schulzrinne, Columbia University
Brian Smith, Cornell University
Doug Shepherd, University of Lancaster, UK
Ralf Steinmetz, University of Darmstadt, Germany
James Sterbenz, GTE
Dan Swinehart, Xerox PARC
Harrick Vin, Univ of Texas, Austin
Raj Yavatkar, Intel
Radu Popescue-Zeletin, GMD FOKUS, Germany
Hui Zhang, CMU
Publicity Chair
Milind M. Buddhikot
Graduate Research Assistant
Department of Computer Science
Washington University, St. Louis MO, USA
milind at dworkin.wustl.edu TELE (314) 935 4302
Publications Chair
Vykky A. Klingenberg
Technical Assistant, Applied Research Laboratory
Department of Computer Science
Washington University, St. Louis MO, USA
vykky at arl.wustl.edu TELE (314) 935 7534
LOCATION
As is traditional, the workshop will take place at an elite resort,
away from the hustle and bustle of daily life. Innsbrook Estates
Executive Conference Center is located on 3,200 acres of the most
gorgeous rolling Missouri woodland, dotted by crystal clear lakes.
For accommodations, there are 1, 2, and 3-bedroom condominiums which
are fully equipped with living and dining areas, fireplaces, cable
television and kitchens to offer conferees all the comforts of home in
a lakeside or wooded hideaway. You want to relax after a day of
lectures? There is an eighteen hole golf-course, a junior-olympic
swimming pool, lighted tennis courts, mini-fitness center with a sauna
and hot tub, softball, volleyball, horseback riding, miniature golf
course, fishing, lake swimming, canoeing, and sailing, just to name a
few of the amenities. A relaxing excursion to a scenic location away
from the conference site is also being planned.
Received: from ietf.org by ietf.org id aa21537; 27 Sep 96 20:15 EDT
Received: from cnri by ietf.org id aa21425; 27 Sep 96 20:10 EDT
Received: from [132.197.8.9] by CNRI.Reston.VA.US id aa04418;
27 Sep 96 20:10 EDT
Received: from [132.197.144.52] by ns.gte.com (8.7.5/)
X-Sender: bk00 at pophost.gte.com
Message-Id: <v02140b03ae721c13aef1 at [132.197.144.52]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 27 Sep 1996 20:09:20 -0400
To: enternet at bbn.com, ietf at CNRI.Reston.VA.US, itc at fokus.gmd.de,
multicomm at cc.bellcore.com, tccc at cs.umass.edu, comsoc-tcii at ieee.com,
cnom at maestro.bellcore.com, commsoft at cc.bellcore.com, comswtc at gmu.edu
Sender:ietf-request at ietf.org
From: Dr Bhumip Khasnabish +1-617-466-2080 <bhumip at gte.com>
Subject: ENM-97 CFP. Thanks.
Source-Info: From (or Sender) name not authenticated.
The IEEE Enterprise Networking Mini-conference (ENM) will
be held in Montreal, Canada on June 11 & 12, 1997.
in conjunction with the ICC-97 (June 8-12, 1997).
Details are available at: http://www.ieee.org/comsoc/ENM-97.html
(paper submission deadline is Nov.15, 1996).
Thanks a lot,
with all the best wishes and regards,
---------------------------------------------------------------------
Dr. Bhumip Khasnabish,
GTE Labs. Inc., Rm.4-292 Tel +1-617-466-2080
40 Sylvan Road, Fax +1-617-890-9320
Waltham MA 02254 Res +1-617-647-5356
U.S.A. E-Mail: bhumip at gte.com
bhumip at acm.org
.....................................................................
GTE IntraNet: http://cnsmacic.gte.com/users/bhumip/
Internet URL: http://www.acm.org:82/~bhumip/
=====================================================================
Received: from ietf.org by ietf.org id aa00429; 27 Sep 96 23:44 EDT
Received: from burnout.cts.com by ietf.org id aa00258; 27 Sep 96 23:41 EDT
Received: from raylutz.cts.com (raylutz.cts.com [198.68.170.124]) by burnout.cts.com (8.6.12/8.6.9) with SMTP id UAA17037; Fri, 27 Sep 1996 20:40:17 -0700
Date: Fri, 27 Sep 1996 20:40:17 -0700
Message-Id: <199609280340.UAA17037 at burnout.cts.com>
X-Sender: raylutz at crash.cts.com
X-Mailer: Windows Eudora Version 2.0.3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Raymond Lutz <raylutz at cognisys.com>
Subject: Integrated Office Conference '96 (IOC'96)
Cc: ietf-fax at imc.org
Source-Info: From (or Sender) name not authenticated.
The Integrated Office Conference '96 will be held October 21-23 in San Diego.
Includes 30+ sessions, many dealing with Interent interoperability with
facsimile, internet remote printing, and scanning. Multifunction Peripherals
is a key focus. See:
http://www.mfpa.org/ioc96.pdf
for details on the conference.
-Raymond Lutz
/***********************************************************************
** Raymond Lutz Voice: 619-447-3246
** Director R & D, Cognisys, Inc. Fax: 619-447-6872
** MFPA EC Chair BBS: 619-447-2223
** 1010 Old Chase Ave., Suite B EMail: raylutz at cognisys.com
** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA
** WWW: http://www.cognisys.com http://www.mfpa.org
***********************************************************************/
Received: from ietf.org by ietf.org id aa14483; 28 Sep 96 16:15 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa14145;
28 Sep 96 16:07 EDT
Received: from SYNW06.elettra.trieste.it by IETF.CNRI.Reston.VA.US id aa01059;
28 Sep 96 16:07 EDT
Date: Sat, 28 Sep 1996 22:06:37 +0200 (CET-DST)
Sender:ietf-request at ietf.org
From: Claudio Allocchio - +39 40 3758523 <ALLOCCHIO at elettra.trieste.it>
To: ietf at IETF.CNRI.Reston.VA.US
CC: ALLOCCHIO at elettra.trieste.it
Message-Id: <960928220637.206008b2 at elettra.trieste.it>
Subject: one example of e-mail abuse commercialized
Source-Info: From (or Sender) name not authenticated.
shall we start considering seriously actions like "deletion of registered
domain name" or "recall of assigned ip addresses" when actions like the
one advertised hereunder appear on the net?
If we want to keep a correct use of resources, may some thinking could
be useful.
Regards
Claudio Allocchio
TERENA WG-MSG - Mail and Messagin
convenor.
-------------------------------
From: Mail AutoResponder <sender at answerme.com>
To: claudio allocchio - +39 40 3758523 <allocchio at elettra.trieste.it>
Thank you for requesting more information on Cyber Promotions' cutting-edge...
AUTO-SENDER service ... "First of its kind!"
Cyber Promotions' new "AUTO-SENDER" package is
every bulk emailers DREAM COME TRUE!!
This package is a fully-tested "all-in-one-box"
solution to your email broadcasting needs.
"AUTO-SENDER" has been designed, programmed, and tested
by Sanford Wallace, the founder/president of Cyber Promotions.
What does the Auto-Sender package consist of?
Our system provides a sending mechanism that can handle over 250,000 email
deliveries an hour, with no repercussions like account terminations for
bulk-email "violations"! To use this service, all you need is an existing
email address. It doesn't matter if you use a Macintosh, IBM, Unix, or
even an old Radio Shack computer... You don't need PPP, SLIP, ISDN or a
T-1... There are no computer memory requirement... You just need an
existing email account on any online service or internet provider. There
will be NO TRACE to your existing email address. You will only use your
existing email address to communicate with our system. Your broadcasted
message will come from Cyber Promotions' servers, it will send through
Cyber Promotions' servers, and people will respond back to Cyber
Promotions' servers. All you have to do is enjoy the benefits and rewards
of this wonderful new medium!
You receive all of the following...
A fully-functional autoresponder for your positive replies.
A virtual email-box for your positive replies.
A redirect service from your virtual email-box to your existing email
address. In other words, if someone emails to your virtual mailbox, the
message will immediately forward to your "real" email address.
Access to our full "master" remove list which we maintain. Your mail will
automatically get compared to that list, and our system will not mail to
people who have sent requests to be removed from all mailing lists.
A "reply" address that is automatically maintained, for recipients to send
remove requests by simply hitting reply and typing "remove". Our systems
will also automatically remove the email addresses of people who reply with
profanities or include statements like "take my name off". There are
actually 45 built-in filters in all.
Our system automatically adds your *undeliverable* email addresses into
your permanent "remove" list.
***NEW*** You can now maintain as many DIFFERENT mailing lists as you wish,
with only one account!
***NEW*** you can now choose to send your message to ONLY people who have
been added to your master list since the last time you sent mail.
You will receive full documentation with EZ instructions on operating your
account. You can preview the instructions if you wish. Send an email to
ASinstructions at answerme.com
(Please note: You are responsible for collecting or buying your own email
addresses.)
_________________________________________
LIST OF EMAIL ADDRESSES THAT YOU WILL RECEIVE WITH OUR PACKAGE:
<your.id>add at omni.cyberpromo.com # to add addresses to your list.
<your.id>setup at omni.cyberpromo.com # to set up your outgoing message.
<your.id>@cyberpromo.com # your virtual email-box.
<your.id>@answerme.com # your autoresponder.
<your.id>remove at omni.cyberpromo.com # to remove addresses.
<your.id>out at cyberpromo.com # your auto-remove address.
<your.id>sender at omni.cyberpromo.com # to send commands.
LIST OF COMMANDS:
TRIAL # Send your message to yourself only.
SEND # Send your message to your full mailing list.
NEWSEND # Send your message to new addresses only.
UPDATE # Update all removes and adds. Get report.
BACKUP ????? # Backup your master lists.
EMPTYTO ????? # Store-away and empty your current master list.
RESTORE ????? # Restore your master list.
LIST # Request a copy of your master list.
STATUS # Check on the status of your mailing.
_________________________________________
Pricing and billing:
$199 one-time setup, prepaid.
$49 a month for maintenence & unlimited toll-free support, prepaid for that
month's service.
$.0001 per email sent ($10/100k) rounded up to the nearest $10 billed on
the 1st of the month following the previous month's usage. Itemized
receipts are available upon request.
No extra fees.
You may cancel your account at any time by contacting Cyber Promotions in
writing.
_________________________________________
So, if you are interested in our "AUTO-SENDER" package...
Print out the following EZ ORDER form, and follow instructions...
If you have any questions, please do not hesitate to call us at:
(800) 650-9110 or (215) 289-4610 or (888) BULK-EMAIL.
----------------------------------------
EZ ORDER FORM:
Simply fill in the blanks...
_____ Yes! I'm interested in your "AUTO-SENDER" package. I would like to
send out my own bulk email efficiently, with no hassles!
COMPANY NAME______________________________________________
YOUR NAME_________________________________________________
YOUR POSITION_____________________________________________
STREET ADDRESS____________________________________________
CITY, STATE, ZIP__________________________________________
PHONE NUMBERS_____________________________________________
FAX NUMBERS_______________________________________________
Your auto-sender "base" ID...
First choice for your ID (2-5 letters)____________________
Second choice for your ID (2-5 letters)___________________
You will be able to set up your outgoing message, through email
at any time. You will need to include a unique password in the subject
field to gain access to your set up system.
Your unique password (6-10 UPPERCASE letters or numbers)_________________
You must use an existing email account on any online service or internet
provider, to send commands to your auto-sender account. Remember, there is
no need for you to worry about losing that account, because it will not be
included on any email broadcasts. Cyber Promotions will be the only people
to know your existing email address. This email address can be changed at
any time. Please indicate your existing email address below:
__________________________________________________________
We accept Visa, Mastercard, AmEx, Discover, Checks by mail or fax, or
Money Order by mail.
The following information will be held in the strictest confidence...
Credit Card: Visa Mastercard AmEx Discover
Card #:_________________________________________
Expiration Date:__________________
Name on Card:___________________________________
I authorize Cyber Promotions to charge me for a one-time $199 set up fee
and a recurring monthly charge of $49 for maintenence & unlimited toll-free
support. In addition I authorize Cyber Promotion to charge $.0001 per
email sent ($10/100k) rounded up to the nearest $10 billed on the 1st of
the month following the previous month's usage. I realize that itemized
receipts are available upon request. I may cancel my account at any time
by contacting Cyber Promotions in writing.
SIGNATURE:x________________________ DATE:x__________________
O R
**********************************************************
PLEASE PASTE YOUR CHECK HERE
(If you fax a check, there is no need for you to send the original
check. We will draft up a new check, with the exact information
from your original check)
**********************************************************
I understand that Cyber Promotions does not guarantee or predict any
type of profit from these services. I authorize Cyber Promotions to charge
an additional $25 fee if my checks are returned for insufficient or
uncollectable funds. I authorize Cyber Promotions to quote any positive
testimonial that I may offer, without prior notice. I am fully authorized
to represent the company that I am advertising. I acknowledge that
Cyber Promotions has the right to refuse my order if they deem
it inappropriate. Cyber Promotions will not be held liable for any
claims that I represent in my advertisements or auto-responder text.
I agree to read Cyber Promotions' Terms of Service when I receive
it with my instructions. If I do not receive or agree to the terms,
I will cancel my order within 30 days, and receive a prompt refund.
If I recklessly disregard Cyber's Terms of Service, I may be held liable
for damages.
SIGNATURE:x________________________ DATE:x__________________
Please fax these forms to: 1-800-650-9230 or 1-215-288-9230 or to our new
backup fax number: (215) 743-3750.
If you fax a check, there is no need for you to send the original
check. We will draft up a new check, with the exact information
from your original check. If you feel more comfortable sending
payment through the mail, please send all forms and check to:
Cyber Promotions
8001 Castor Avenue, Suite #127
Philadelphia, PA 19152
* * * * * * * * * * * * * * * * * * * * * * * * * *
We will set up your new auto-sender account within 3 business days.
At that time, we will email you confirmation and instructions on
how to use it. We will also be happy to assist you with your
new account.
* * * * * * * * * * * * * * * * * * * * * * * * * *
The entire contents of this message are copyrighted and protected by
both United States copyright laws and international treaty provisions.
None of the text in this message may ever be reproduced, in original
or modified form, for commercial purposes, without express written
permission by Cyber Promotions. We do authorize and encourage the
forwarding of this message to interested parties, for the purpose of
informing them of Cyber Promotions' services.
If you have any questions, please feel free to call:
(800) 650-9110 or (215) 289-4610
Copyright 1996 - All rights reserved.
< end >
Received: from ietf.org by ietf.org id aa16498; 28 Sep 96 18:37 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa16412;
28 Sep 96 18:32 EDT
Received: from dns.IT.net by IETF.CNRI.Reston.VA.US id aa01156;
28 Sep 96 18:32 EDT
Received: from pint001.pn.itnet.it (pint001.pn.ITnet.it [151.2.28.5]) by dns.it.net (8.6.9/8.6.9) with SMTP id AAA08569; Sun, 29 Sep 1996 00:31:49 +0200
Message-Id: <1.5.4.32.19960928230302.006b8b68 at 151.1.1.1>
X-Sender: pint001 at 151.1.1.1
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 29 Sep 1996 01:03:02 +0200
To: ietf at IETF.CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: Ivan Pintori <pint001 at it.net>
Subject: Re: one example of e-mail abuse commercialized
Cc: ALLOCCHIO at elettra.trieste.it
Source-Info: From (or Sender) name not authenticated.
At 22.06 28/09/96 +0200, Claudio Allocchio - +39 40 3758523 wrote:
>
>shall we start considering seriously actions like "deletion of registered
>domain name" or "recall of assigned ip addresses" when actions like the
>one advertised hereunder appear on the net?
I did receive such a mail, alas, and as Claudio is suggesting, there MUST
some way to stop this abuse. The last that i have seen is a 25mb gzipped
mailbox of abusive e-mails to a religious organization. Franckly this should
be stopped somehow (I don't want to go back to the office on monday morning
just to discover that I have to gzip another full mailbox!)
>Regards
>Claudio Allocchio
>TERENA WG-MSG - Mail and Messagin
>convenor.
Ivan Pintori
ITnet spa / Internet Office of the Hole See Administration group
Received: from ietf.org by ietf.org id aa17338; 28 Sep 96 19:07 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa17164;
28 Sep 96 19:04 EDT
Received: from mail3.microsoft.com by IETF.CNRI.Reston.VA.US id aa01185;
28 Sep 96 19:04 EDT
Received: by mail3.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5)
id <01BBAD57.0DED8310 at mail3.microsoft.com>; Sat, 28 Sep 1996 16:06:49 -0700
Message-ID: <c=US%a=_%p=msft%l=RED-71-MSG-960928230352Z-14916 at mail3.microsoft.com>
Sender:ietf-request at ietf.org
From: Andrew Nicholson <andyni at microsoft.com>
To: "'ietf at IETF.CNRI.Reston.VA.US'" <ietf at IETF.CNRI.Reston.VA.US>
Cc: "'ALLOCCHIO at elettra.trieste.it'" <ALLOCCHIO at elettra.trieste.it>,
'Ivan Pintori' <pint001 at it.net>
Subject: RE: one example of e-mail abuse commercialized
Date: Sat, 28 Sep 1996 16:03:52 -0700
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
Encoding: 43 TEXT
Source-Info: From (or Sender) name not authenticated.
As long as the senders of junk or bulk email do not have to pay the true
and full cost of the transmission, there will continue to be junk and
bulk email, regardless of patches anyone tries to create to prevent the
abuse of this economic flaw of the cost recapture mechanism of the
Internet.
The only solution will be to create a cost recapture mechanism which
burdens the sender with the cost of email rather than the recipient,
like the postal systems do now. Otherwise the economic incentive of
poor citizenship is too much to resist for those inclined to theft of
other people's resources.
Cheers!
Andy Nicholson
>----------
>From:Ivan Pintori[SMTP:pint001 at it.net]
>Sent:Saturday, September 28, 1996 4:03 PM
>To:ietf at IETF.CNRI.Reston.VA.US
>Cc:ALLOCCHIO at elettra.trieste.it
>Subject:Re: one example of e-mail abuse commercialized
>
>At 22.06 28/09/96 +0200, Claudio Allocchio - +39 40 3758523 wrote:
>>
>>shall we start considering seriously actions like "deletion of registered
>>domain name" or "recall of assigned ip addresses" when actions like the
>>one advertised hereunder appear on the net?
>
>I did receive such a mail, alas, and as Claudio is suggesting, there MUST
>some way to stop this abuse. The last that i have seen is a 25mb gzipped
>mailbox of abusive e-mails to a religious organization. Franckly this should
>be stopped somehow (I don't want to go back to the office on monday morning
>just to discover that I have to gzip another full mailbox!)
>
>>Regards
>>Claudio Allocchio
>>TERENA WG-MSG - Mail and Messagin
>>convenor.
>
>Ivan Pintori
>ITnet spa / Internet Office of the Hole See Administration group
>
>
Received: from ietf.org by ietf.org id aa27865; 29 Sep 96 0:31 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa27623; 29 Sep 96 0:24 EDT
Received: from galileo.starnetc.com by IETF.CNRI.Reston.VA.US id aa00516;
29 Sep 96 0:24 EDT
Received: from rune.starnetc.com (molten.starnetc.com [204.244.147.199]) by galileo.starnetc.com (8.7.5/8.7.3) with SMTP id UAA16215 for <ietf at IETF.CNRI.Reston.VA.US>; Sat, 28 Sep 1996 20:04:59 -0700 (PDT)
Message-Id: <3.0b26.32.19960928212149.00ab3d3c at starnetc.com>
X-Sender: jasonb at starnetc.com
X-Mailer: Windows Eudora Pro Version 3.0b26 (32)
Date: Sat, 28 Sep 1996 21:21:53 -0700
To: ietf at IETF.CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: Jason Bolduc <Jasonb at globalimage.com>
Subject: one example of e-mail abuse commercialized
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
While we're on the subject of commercial e-mail abuse,
I thought I'd share the latest piece of junk I got on my
mailbox. Especially watch the subject line..
Somebody just entered themselves into my blacklist.
Jason Bolduc
-----
From: Lsat at Lsat.com
Date: Sat, 28 Sep 1996 20:57:48 PDT
Subject: E M E R G E N C Y !!!
!!!!!!!!!!! FREE INTERNET ACCESS !!!!!!!!!!!
NEVER EVER pay for Internet Access AGAIN!!! E-V-E-R!
Amazing Course on Audio Tape describes STEP by STEP what your Internet
Service Provider doesn't want you to know!
* How to get FREE LOCAL DIAL-UP PPP Internet Access!
* How to Surf the Web,Newsgroups,and EMAIL Anonymously/Untraceable!
* How to Make VOICE Phone Calls ANYWHERE in the World UNTRACEABLE!
* Where you can get FREE Email Remailing
* Where you can get FREE Email Addresses
* Where you can get FREE Access to News Servers
* How to get FREE Internet Tools for Email, News, WWW, Etc.
* How to get free accounts on BBS's
* MUCH MUCH More!!!
No matter where you live in the world we guarantee you will get FREE
internet access legally and anonymously!
Received: from ietf.org by ietf.org id aa00925; 29 Sep 96 3:45 EDT
Received: from tomobiki-cho.cac.washington.edu by ietf.org id aa00834;
29 Sep 96 3:40 EDT
Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU
(8.7.5/UW-NDC Revision: 2.28 ) id AAA19501; Sun, 29 Sep 1996 00:40:16 -0700 (PDT)
Received: from localhost by Ikkoku-Kan.Panda.COM
(NX5.67e/UW-NDC/Panda Revision: 2.27.MRC ) id AA00551; Sun, 29 Sep 96 00:40:12 -0700
Date: Sun, 29 Sep 1996 00:21:27 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: one example of e-mail abuse commercialized
To: ietf at ietf.org
Message-Id: <MailManager.843981687.286.mrc at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
One of the worst sources of junk email on the Internet today is interramp.com,
a subsidiary of PSI. People have complained to PSI for a long time, and PSI
has done nothing to stop it. I've come to the conclusion that PSI does not
care.
The most recent mailing comes from a disreputable outfit called "Victory
Press" in California. Judging from the "Apparently-To:" lines, the crooks
have a sorted list of email addresses and send it to 25 addresses at a time.
Most of the other victims were at AOL.
Like AOL, I've resorted to blocking. I block all IP packets coming from PSI's
network 38 to my private network. Unfortunately I haven't yet convinced the
management of the network at my day job to do the same.
If you can't get your router guys to block PSI for you, you can very
effectively block PSI on your own workstation by the command (executed as
root):
/usr/etc/route add net 38.0.0.0 localhost 0
Your mail spool directory will thank you.
Received: from ietf.org by ietf.org id aa02333; 29 Sep 96 5:08 EDT
Received: from cnri by ietf.org id aa02275; 29 Sep 96 5:05 EDT
Received: from cactus.silkroad.com by CNRI.Reston.VA.US id aa21777;
29 Sep 96 5:05 EDT
Received: (from bass at localhost) by cactus.silkroad.com (8.6.12/8.6.9) id FAA08829; Sun, 29 Sep 1996 05:04:29 -0400
Sender:ietf-request at ietf.org
From: Tim Bass <bass at cactus.silkroad.com>
Message-Id: <199609290904.FAA08829 at cactus.silkroad.com>
Subject: PAPER: An Overview of NSFNET 4090 Awards 1986-1996
To: nanog at merit.edu
Date: Sun, 29 Sep 1996 05:04:29 -0400 (EDT)
Cc: ietf at CNRI.Reston.VA.US
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 594
Source-Info: From (or Sender) name not authenticated.
I promised NANOG a paper on NSFNET funding and then dropped off the
map (to get some real work done...). It is now available:
An Overview of NSFNET 4090 Awards 1986-1996
-------------------------------------------
http://www.silkroad.com/papers/ (postscript format only)
There is certainly plenty of controversial issues for the readers
enjoyment ;)
Comments, both positive and negative welcome (however the chances
of getting a reply are better with positive comments :-).
Best Regards,
Tim
--FAB08813.843987723/cactus.silkroad.com--
Received: from ietf.org by ietf.org id aa07699; 29 Sep 96 11:32 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa07547;
29 Sep 96 11:27 EDT
Received: from itchy.mindspring.com by IETF.CNRI.Reston.VA.US id aa00907;
29 Sep 96 11:27 EDT
Received: from monster.mindspring.com (monster.mindspring.com [204.180.142.23]) by itchy.mindspring.com (8.7.5/8.7.3) with SMTP id LAA03967; Sun, 29 Sep 1996 11:26:55 -0400 (EDT)
Date: Sun, 29 Sep 1996 11:26:55 -0400 (EDT)
Message-Id: <199609291526.LAA03967 at itchy.mindspring.com>
X-Sender: bob at mindspring.com
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at IETF.CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: Bob McNamara <bob at mindspring.com>
Subject: Re: one example of e-mail abuse commercialized
Cc: Mark Crispin <MRC at panda.com>
Source-Info: From (or Sender) name not authenticated.
I'd like to strongly speak out against this blanket type of retribution.
While the blocking of a single domain (cyberpromo.com) from AOL is widely
applauded, it is common knowledge that no traffic other than spam ever
originates from there. By choosing to block PSI's traffic you not only
intercept the traffic of some abuses, but deny acess to your users to
tens of thousands of innocent and polite net citizens. Any such action
by any group only impacts the innocent, and has no effect at all on the
nefarious.
On the positive side, good responsiveness can make a difference. The dialup
customers of PSI's Interramp and Pipeline service are in the process of
being converted to MindSpring customers. MindSpring has never, and has to
plans to ever offer the '14 day free' trials that Interramp was popular for,
and have been the source of so much net-abuse. Our policies are very simple,
we are a 'one strike' company. A short perusal of news.admin.net-abuse.misc
will show a growing pleasure with the number of Interramp spammers we've
terminated, and the speed with which we've done it.
This is the policy people should be demanding from providers. Quick,
rational and effective action.
As I was taught at an early age, one does not throw out the baby with the
bathwater. IP blocking at the level you advocate does exactly that.
Until there are better technological methods, something I look to this
organization to help provide, which work effectively on the scale large
providers require, to prevent net-abuse at the originating point the only
action which can be taken is reactive, and strong swift reactive stances
are what every individual should be demanding.
Bob
At 12:21 AM 9/29/96 -0700, you wrote:
(snip)
>Like AOL, I've resorted to blocking. I block all IP packets coming from PSI's
>network 38 to my private network. Unfortunately I haven't yet convinced the
>management of the network at my day job to do the same.
>
>If you can't get your router guys to block PSI for you, you can very
>effectively block PSI on your own workstation by the command (executed as
>root):
>/usr/etc/route add net 38.0.0.0 localhost 0
>Your mail spool directory will thank you.
>
>
- - - - - - - - - - - - -
Bob
Bob McNamara bob at mindspring.com
MindSpring Evangelist, MindSpring Staff
MindSpring Enterprises Inc.
1430 W. Peachtree Atlanta, GA 30309
(404) 815 0770 x 2205 (800) 719 4332 x 2205
http://www.mindspring.com
"A ship is safe in the harbor, but that is not why ships are built"
Received: from ietf.org by ietf.org id aa08633; 29 Sep 96 12:11 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa08563;
29 Sep 96 12:08 EDT
Received: from tomobiki-cho.cac.washington.edu by IETF.CNRI.Reston.VA.US
id aa00932; 29 Sep 96 12:08 EDT
Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU
(8.7.5/UW-NDC Revision: 2.28 ) id JAA19806; Sun, 29 Sep 1996 09:07:54 -0700 (PDT)
Received: from localhost by Ikkoku-Kan.Panda.COM
(NX5.67e/UW-NDC/Panda Revision: 2.27.MRC ) id AA01958; Sun, 29 Sep 96 09:07:49 -0700
Date: Sun, 29 Sep 1996 08:55:28 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: Re: one example of e-mail abuse commercialized
To: Bob McNamara <bob at mindspring.com>
Cc: ietf at IETF.CNRI.Reston.VA.US
In-Reply-To: <199609291526.LAA03967 at itchy.mindspring.com>
Message-Id: <MailManager.844012528.286.mrc at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sun, 29 Sep 1996 11:26:55 -0400 (EDT), Bob McNamara wrote:
> While the blocking of a single domain (cyberpromo.com) from AOL is widely
> applauded, it is common knowledge that no traffic other than spam ever
> originates from there. By choosing to block PSI's traffic you not only
> intercept the traffic of some abuses, but deny acess to your users to
> tens of thousands of innocent and polite net citizens. Any such action
> by any group only impacts the innocent, and has no effect at all on the
> nefarious.
Before blocking PSI, I checked. To my site, no traffic other than spam
originates from PSI. Nor am I the only site that has taken this kind of
action against PSI and other bad citizen ISPs.
The last straw was when PSI-originated spam cost me the loss of a valuable
resource last month.
Blocking a bad citizen ISP has a very important side effect; if innocent
customers of that ISP become unable to do their work because of blocking, they
will find a new ISP that isn't blocked. That, if nothing else, will get the
ISP's attention.
> Until there are better technological methods, something I look to this
> organization to help provide, which work effectively on the scale large
> providers require, to prevent net-abuse at the originating point the only
> action which can be taken is reactive, and strong swift reactive stances
> are what every individual should be demanding.
Reactive methods are no longer helpful due to the use of throwaway accounts.
The abusers don't care if they have to pay for the account. The cost is
small, and they'll get another one using a new DBA or alias. We are seeing
this happen. I don't think that Mindspring's "one strike" policy will make a
whit of difference.
Received: from ietf.org by ietf.org id aa11891; 29 Sep 96 16:02 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa11794;
29 Sep 96 15:57 EDT
Received: from nova.unix.portal.com by IETF.CNRI.Reston.VA.US id aa01071;
29 Sep 96 15:57 EDT
Received: from jobe.shell.portal.com (jobe.shell.portal.com [156.151.3.4]) by nova.unix.portal.com (8.6.11/8.6.5) with ESMTP id MAA00256; Sun, 29 Sep 1996 12:55:15 -0700
Received: from localhost (dwm at localhost) by jobe.shell.portal.com (8.6.11/8.6.5) with SMTP id MAA19081; Sun, 29 Sep 1996 12:54:45 -0700
Date: Sun, 29 Sep 1996 12:54:45 -0700 (PDT)
Sender:ietf-request at ietf.org
From: "David W. Morris" <dwm at shell.portal.com>
To: Mark Crispin <MRC at panda.com>
cc: Bob McNamara <bob at mindspring.com>, ietf at IETF.CNRI.Reston.VA.US
Subject: Re: one example of e-mail abuse commercialized
In-Reply-To: <MailManager.844012528.286.mrc at Ikkoku-Kan.Panda.COM>
Message-ID: <Pine.SUN.3.93.960929125141.18805B-100000 at jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sun, 29 Sep 1996, Mark Crispin wrote:
> On Sun, 29 Sep 1996 11:26:55 -0400 (EDT), Bob McNamara wrote:
> > by any group only impacts the innocent, and has no effect at all on the
> > nefarious.
>
> Before blocking PSI, I checked. To my site, no traffic other than spam
> originates from PSI. Nor am I the only site that has taken this kind of
> action against PSI and other bad citizen ISPs.
>
> The last straw was when PSI-originated spam cost me the loss of a valuable
> resource last month.
I must agree with Mark ... PSI will only start taking this seriously when
their customers leave because they spamming impacts them directly and this
is the only way recipients have today to make spamming cost the sender
more than the recipient. If mindspring doesn't like the association with
PSI then mindspring can find a new provider.
Dave Morris
Received: from ietf.org by ietf.org id aa13640; 29 Sep 96 17:40 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa13540;
29 Sep 96 17:35 EDT
Received: from answerman.mindspring.com by IETF.CNRI.Reston.VA.US id aa01141;
29 Sep 96 17:35 EDT
Received: from monster.mindspring.com (monster.mindspring.com [204.180.142.23]) by answerman.mindspring.com (8.7.5/8.7.3) with SMTP id RAA17749 for <ietf at IETF.CNRI.Reston.VA.US>; Sun, 29 Sep 1996 17:35:10 -0400 (EDT)
Date: Sun, 29 Sep 1996 17:35:10 -0400 (EDT)
Message-Id: <199609292135.RAA17749 at answerman.mindspring.com>
X-Sender: bob at mindspring.com
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at IETF.CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: Bob McNamara <bob at mindspring.com>
Subject: Re: one example of e-mail abuse commercialized
Source-Info: From (or Sender) name not authenticated.
At 12:54 PM 9/29/96 -0700, you wrote:
>
>
>On Sun, 29 Sep 1996, Mark Crispin wrote:
>I must agree with Mark ... PSI will only start taking this seriously when
>their customers leave because they spamming impacts them directly and this
>is the only way recipients have today to make spamming cost the sender
>more than the recipient. If mindspring doesn't like the association with
>PSI then mindspring can find a new provider.
>
>Dave Morris
I don't think you understand.
This paragraph ...
"On the positive side, good responsiveness can make a difference. The dialup
customers of PSI's Interramp and Pipeline service are in the process of
being converted to MindSpring customers. MindSpring has never, and has no
plans to ever offer the '14 day free' trials that Interramp was popular for,
and have been the source of so much net-abuse. Our policies are very simple,
we are a 'one strike' company. A short perusal of news.admin.net-abuse.misc
will show a growing pleasure with the number of Interramp spammers we've
terminated, and the speed with which we've done it. "
says ....
The spammers that have caused trouble for PSI are primarily Interramp dialup
customers, often using 14 day free trial accounts.
We (MindSpring) have purchased those subscribers (all the dialup subscribers
of Interramp and Pipeline) and are transferring them to our service now.
We (MindSpring), have never offered, and have no plans to offer any 'no
money up front' activations.
Abuse which occurs from an interramp.com, pipeline.com or mindspring.com
addresses now results in termination, by us, of the account in some of the
fastest times on the planet. We don't like spam.
MindSpring does not need to 'find a new provider', MindSpring is now one of
the larger providers in the U.S.
PSI is getting out of the dialup business, beating up on PSI is beating on a
horse which has already left the race.
There will be no more interramp.com dialup addresses by the end of October.
The interramp.com domain is being retained by PSI for its commercial customers.
I do not understand how anyone who read the referenced paragraph could have
misconstrued it's meaning, but obviously that has been the case. I stand by
my original response to Mr. Crispin that the tactics he is using are wrong
and counterproductive. Blocking inbound traffic from innocent users, for
whatever reason, is wrong. I'd be happy to continue this discussion in
news.admin.net-abuse.misc, where you will find much more information on the
topic, and where it really belongs.
Bob
- - - - - - - - - - - - -
Bob
Bob McNamara bob at mindspring.com
MindSpring Evangelist, MindSpring Staff
MindSpring Enterprises Inc.
1430 W. Peachtree Atlanta, GA 30309
(404) 815 0770 x 2205 (800) 719 4332 x 2205
http://www.mindspring.com
"A ship is safe in the harbor, but that is not why ships are built"
Received: from ietf.org by ietf.org id aa14411; 29 Sep 96 18:07 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa14335;
29 Sep 96 18:05 EDT
Received: from mail.ima.com by IETF.CNRI.Reston.VA.US id aa01163;
29 Sep 96 18:05 EDT
Return-Path: <kehres at ima.net>
Received: from ima.net by mail.ima.com (8.6.12/1.14.5) with ESMTP
id GAA04062; Mon, 30 Sep 1996 06:04:30 +0800
Received: by ima.net (8.6.12/1.14.5)
id GAA07569; Mon, 30 Sep 1996 06:02:29 +0800
Date: Mon, 30 Sep 1996 06:02:29 +0800 (HKT)
Sender:ietf-request at ietf.org
From: Tim Kehres <kehres at ima.com>
X-Sender: kehres at ima.net
To: Mark Crispin <MRC at panda.com>
cc: Bob McNamara <bob at mindspring.com>, ietf at IETF.CNRI.Reston.VA.US
Subject: Re: one example of e-mail abuse commercialized
In-Reply-To: <MailManager.844012528.286.mrc at Ikkoku-Kan.Panda.COM>
Message-ID: <Pine.LNX.3.91.960930055601.7513D-100000 at ima.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sun, 29 Sep 1996, Mark Crispin wrote:
> On Sun, 29 Sep 1996 11:26:55 -0400 (EDT), Bob McNamara wrote:
> > While the blocking of a single domain (cyberpromo.com) from AOL is widely
> > applauded, it is common knowledge that no traffic other than spam ever
> > originates from there. By choosing to block PSI's traffic you not only
> > intercept the traffic of some abuses, but deny acess to your users to
> > tens of thousands of innocent and polite net citizens. Any such action
> > by any group only impacts the innocent, and has no effect at all on the
> > nefarious.
>
> Before blocking PSI, I checked. To my site, no traffic other than spam
> originates from PSI. Nor am I the only site that has taken this kind of
> action against PSI and other bad citizen ISPs.
While I agree with Mark regarding the need to be able to have some kind
of recourse against blatent spammers, I am also in agreement with Bob
that this is not the proper solution. PSI also handles mail forwarding
for many companies (through their ISDN services among others), which
would in our case cut us off from one of our key accounts.
And then there is also the issue that all the spammers whould have to do
to get around the IP blocking would be to route their email through
another host, not being blocked. The last time I've done this (to get
around GSL routing problems) it only took a line or two change in the
local sendmail.cf file. With workarounds as simple as this, the impact
would most likely be feft by the innocent users, and not those whom are
causing the problems.
Best Regards,
Tim Kehres
International Messaging Associates Ltd
Received: from ietf.org by ietf.org id aa15563; 29 Sep 96 19:01 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa15455;
29 Sep 96 18:57 EDT
Received: from nova.unix.portal.com by IETF.CNRI.Reston.VA.US id aa01193;
29 Sep 96 18:57 EDT
Received: from jobe.shell.portal.com (jobe.shell.portal.com [156.151.3.4]) by nova.unix.portal.com (8.6.11/8.6.5) with ESMTP id PAA05526; Sun, 29 Sep 1996 15:55:10 -0700
Received: from localhost (dwm at localhost) by jobe.shell.portal.com (8.6.11/8.6.5) with SMTP id PAA23871; Sun, 29 Sep 1996 15:54:39 -0700
Date: Sun, 29 Sep 1996 15:54:39 -0700 (PDT)
Sender:ietf-request at ietf.org
From: "David W. Morris" <dwm at shell.portal.com>
To: Bob McNamara <bob at mindspring.com>
cc: ietf at IETF.CNRI.Reston.VA.US
Subject: Re: one example of e-mail abuse commercialized
In-Reply-To: <199609292135.RAA17749 at answerman.mindspring.com>
Message-ID: <Pine.SUN.3.93.960929154353.23369B-100000 at jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sun, 29 Sep 1996, Bob McNamara wrote:
> At 12:54 PM 9/29/96 -0700, you wrote:
> >
> >
> >On Sun, 29 Sep 1996, Mark Crispin wrote:
> >I must agree with Mark ... PSI will only start taking this seriously when
> >their customers leave because they spamming impacts them directly and this
> >is the only way recipients have today to make spamming cost the sender
> >more than the recipient. If mindspring doesn't like the association with
> >PSI then mindspring can find a new provider.
> >
> >Dave Morris
>
> I don't think you understand.
What I understood what that your company's business would be impacted by
blocking of PSI's class-A address ... my basic points were and remain:
1. Anything which forces ISPs such as PSI to be more responsible need to
be done ... only if their customers walk will they change their
policies
2. If your company was tarred by association with PSIs class-A address,
they you should find a new ISP.
I understood your different business practices as perhaps helping and was
not suggesting your approach was wrong, only that if you cared about
Mark's blocking your customers you should find a new connection to
the Internet.
There will be less breakage to the overall Internet by blocking traffic
from individual networks than caused by the spamming.
Dave Morris
Received: from ietf.org by ietf.org id aa17922; 29 Sep 96 21:09 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa17827;
29 Sep 96 21:05 EDT
Received: from trystero.media.org by IETF.CNRI.Reston.VA.US id aa01263;
29 Sep 96 21:05 EDT
Received: (carl at localhost) by trystero.media.org (8.7.6/960629.01bjb) id VAA17946; Sun, 29 Sep 1996 21:04:31 -0400 (EDT)
Sender:ietf-request at ietf.org
From: "Carl Malamud [IMS]" <carl at media.org>
Message-Id: <199609300104.VAA17946 at trystero.media.org>
Subject: Re: one example of e-mail abuse commercialized
To: "David W. Morris" <dwm at shell.portal.com>
Date: Sun, 29 Sep 1996 21:04:30 -0400 (EDT)
Cc: bob at mindspring.com, ietf at IETF.CNRI.Reston.VA.US
In-Reply-To: <Pine.SUN.3.93.960929154353.23369B-100000 at jobe.shell.portal.com> from "David W. Morris" at Sep 29, 96 03:54:39 pm
Organization: Internet Multicasting Service
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.
I don't think you've been listening to what Bob Morris from
Mindspring has been saying. PSI's service is under new
management and it sure sounds like the new owners are taking
an agressive stand on spam.
I certainly deplore PSI's lack of community spirit, and I
think that is just one of the reasons they found themselves
unable to run a successful service for end users. Perhaps
it makes sense to give the new owners a chance?
Carl
According to David W. Morris:
>
>
>
> On Sun, 29 Sep 1996, Bob McNamara wrote:
>
> > At 12:54 PM 9/29/96 -0700, you wrote:
> > >
> > >
> > >On Sun, 29 Sep 1996, Mark Crispin wrote:
> > >I must agree with Mark ... PSI will only start taking this seriously when
> > >their customers leave because they spamming impacts them directly and this
> > >is the only way recipients have today to make spamming cost the sender
> > >more than the recipient. If mindspring doesn't like the association with
> > >PSI then mindspring can find a new provider.
> > >
> > >Dave Morris
> >
> > I don't think you understand.
>
> What I understood what that your company's business would be impacted by
> blocking of PSI's class-A address ... my basic points were and remain:
>
> 1. Anything which forces ISPs such as PSI to be more responsible need to
> be done ... only if their customers walk will they change their
> policies
> 2. If your company was tarred by association with PSIs class-A address,
> they you should find a new ISP.
>
> I understood your different business practices as perhaps helping and was
> not suggesting your approach was wrong, only that if you cared about
> Mark's blocking your customers you should find a new connection to
> the Internet.
>
> There will be less breakage to the overall Internet by blocking traffic
> from individual networks than caused by the spamming.
>
> Dave Morris
>
Received: from ietf.org by ietf.org id aa18538; 29 Sep 96 21:37 EDT
Received: from cnri by ietf.org id aa18475; 29 Sep 96 21:34 EDT
Received: from uucp13.netcom.com by CNRI.Reston.VA.US id aa24852;
29 Sep 96 21:34 EDT
Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1)
id SAA25607; Sun, 29 Sep 1996 18:10:24 -0700
Received: (from vjs at localhost) by calcite.rhyolite.com (8.7.3/8.7.3) id RAA26539 for ietf at nri.reston.va.us; Sun, 29 Sep 1996 17:49:55 -0600 (MDT)
Date: Sun, 29 Sep 1996 17:49:55 -0600 (MDT)
Sender:ietf-request at ietf.org
From: Vernon Schryver <vjs at calcite.rhyolite.com>
Message-Id: <199609292349.RAA26539 at calcite.rhyolite.com>
To: ietf at nri.reston.va.us
Subject: Re: one example of e-mail abuse commercialized
Source-Info: From (or Sender) name not authenticated.
To: ietf at nri.reston.va.us
Subject: Re: one example of e-mail abuse commercialized
--------------------
> From: Bob McNamara <bob at mindspring.com>
> ...
> MindSpring does not need to 'find a new provider', MindSpring is now one of
> the larger providers in the U.S.
But perhaps only as long as MindSpring is not considered a rogue provider
and "shunned."
> PSI is getting out of the dialup business, beating up on PSI is beating on a
> horse which has already left the race.
That is might be comforting to those who do not have email addresses
or read netnews. The rest of us receive too much spam from or on
behalf of PSI's commercial accounts.
> ...
> I do not understand how anyone who read the referenced paragraph could have
> misconstrued it's meaning, but obviously that has been the case.
The main misconstruing I've see has been by Mr. McNamara. Yes, we all
hope that MindSpring will clean up the PSI dial-up mess. We hope that
MindSpring's policies will drive the transmissions of willfull spammers
elsewhere, and effectively educate the unthinking, one-time spammers.
> I stand by
> my original response to Mr. Crispin that the tactics he is using are wrong
> and counterproductive.
Wrong?!? If you run a business that steals from others or just
supports thieves, you have no valid complaint if people completely
refuse to deal with you, even when you are not doing bad things.
The tactic of shunning entire ISP's is far from "counterproductive,"
except when you are in the business of selling network access to
spammers. That the tactic is productive can be seen from the earthlink
and other sagas. Without the very real threat of UDP, many observers
feel those problems would have continued. It is also plausible that
one of the reasons PSI is leaving of the dial-up business is that the
cost of educating naive users about spam and detecting the Krazy Kevins
and Jeff Slaytons was too expensive, and those costs were significantly
increased by the threats of UDP and the stream of email complaints
and bad press.
> Blocking inbound traffic from innocent users, for
> whatever reason, is wrong.
Wrong?!? That statement is offensive. Consider a grocery wholesaler
that keeps its prices down with a little extortion, murder, and robbery
on the side. Would it be right or wrong to patronize grocery stores
that don't move any stolen merchandise but that deal with the
criminal wholesaler?
There is no such thing as an "innocent user" of a rogue ISP. There
can be uniformed users (or purchasing agents at grocery stores) who
don't know what they're doing, but by supporting a rogue ISP (or
mob-run wholesaler), all of its customers are guilty of supporting
spam (or worse).
> I'd be happy to continue this discussion in
> news.admin.net-abuse.misc, where you will find much more information on the
> topic, and where it really belongs.
Perhaps this dicussion also belongs on the com-priv mailing list
(ironically hosted on psi.com).
I am disappointed by Mr. McNamara's statements. They sound too much
like the familiar blather of rogue ISP's trying to avoid responsibility
for their (in)actions. If Mr. McNamara has been following the
discussions in news.admin.net-abuse.misc, he knows that Mindspring
and all customers of Mindspring will be held accountable for how they
deal or fail to deal with spam. This includes simply selling
home-accounts to spammers. If a throw-away account on some other ISP
is used to advertize magazines or green cards for a home account on
a Mindspring system, both ISP's are and will be held accountable. If
you don't like that, you're welcome to join cyberpromo.com.
Vernon Schryver, vjs at rhyolite.com
Received: from ietf.org by ietf.org id aa19595; 29 Sep 96 22:13 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa19489;
29 Sep 96 22:10 EDT
Received: from jekyll.piermont.com by IETF.CNRI.Reston.VA.US id aa01311;
29 Sep 96 22:10 EDT
Received: from localhost (perry at localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id WAA09693 for <ietf at ietf.cnri.reston.va.us>; Sun, 29 Sep 1996 22:09:27 -0400 (EDT)
Message-Id: <199609300209.WAA09693 at jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry at localhost didn't use HELO protocol
To: ietf at IETF.CNRI.Reston.VA.US
Subject: Re: one example of e-mail abuse commercialized
In-reply-to: Your message of "Sun, 29 Sep 1996 08:55:28 PDT."
<MailManager.844012528.286.mrc at Ikkoku-Kan.Panda.COM>
Reply-To: perry at piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Sun, 29 Sep 1996 22:09:27 -0400
Sender:ietf-request at ietf.org
From: "Perry E. Metzger" <perry at piermont.com>
Source-Info: From (or Sender) name not authenticated.
Mark Crispin writes:
> Before blocking PSI, I checked. To my site, no traffic other than spam
> originates from PSI.
I agree that my postings are not always the best, Mark, but I'm not
sure I'd classify them as "spam."
Yes, I'm a poor, besotten PSI customer. They had the low bid when I
was looking for a leased line. Now, my particular IP addresses
originate from a block that PSI has other than network 38, but I
believe that other PSI leased line customers do originate from network
38.
If you are going to block PSI's stuff, at least only block stuff
originating from InterRamp, and not PSI in general.
Perry
Received: from ietf.org by ietf.org id aa21732; 29 Sep 96 22:50 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa21493;
29 Sep 96 22:47 EDT
Received: from WLV.IIPO.GTEGSC.COM by IETF.CNRI.Reston.VA.US id aa01337;
29 Sep 96 22:47 EDT
Received: from SPIELZEUG.IIPO.GTEGSC.COM (SPIELZEUG.IIPO.GTEGSC.COM [199.107.242.241]) by wlv.iipo.gtegsc.com (8.7.4/8.7.3) with SMTP id TAA03034; Sun, 29 Sep 1996 19:35:21 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Merton Campbell Crockett <mcc at wlv.iipo.gtegsc.com>
Message-Id: <960929193521.ZM3702 at SPIELZEUG.IIPO.GTEGSC.COM>
Date: Sun, 29 Sep 1996 19:35:13 -0700
In-Reply-To: "David W. Morris" <dwm at shell.portal.com>
"Re: one example of e-mail abuse commercialized" (Sep 29, 12:54)
References: <Pine.SUN.3.93.960929125141.18805B-100000 at jobe.shell.portal.com>
X-Mailer: Z-Mail 4.0.1 (4.0.1 Apr 9 1996)
To: "David W. Morris" <dwm at shell.portal.com>, Mark Crispin <MRC at panda.com>
Subject: Re: one example of e-mail abuse commercialized
Cc: Bob McNamara <bob at mindspring.com>, ietf at IETF.CNRI.Reston.VA.US
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
On Sep 29, 12:54, David W. Morris wrote:
> Subject: Re: one example of e-mail abuse commercialized
}
}
}On Sun, 29 Sep 1996, Mark Crispin wrote:
}
}> On Sun, 29 Sep 1996 11:26:55 -0400 (EDT), Bob McNamara wrote:
}> > by any group only impacts the innocent, and has no effect at all on the
}> > nefarious.
}>
}> Before blocking PSI, I checked. To my site, no traffic other than spam
}> originates from PSI. Nor am I the only site that has taken this kind of
}> action against PSI and other bad citizen ISPs.
}>
}> The last straw was when PSI-originated spam cost me the loss of a valuable
}> resource last month.
}
}I must agree with Mark ... PSI will only start taking this seriously when
}their customers leave because they spamming impacts them directly and this
}is the only way recipients have today to make spamming cost the sender
}more than the recipient. If mindspring doesn't like the association with
}PSI then mindspring can find a new provider.
I believe that I saw a Wall Street Journal article indicating that PSI has
sold its retail business and is concentrating on the wholesale, long-haul,
market.
I interpreted McNamara's comments to mean that Mindspring has acquired the
retail business of PSI and that he was explaining what Mindspring is doing
about some of the abuses that occurred under PSI's ownership.
Merton Campbell Crockett
Hasnthaler InfoSysteme
Received: from ietf.org by ietf.org id aa02488; 30 Sep 96 5:13 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa02376; 30 Sep 96 5:06 EDT
Received: from [193.128.143.64] by IETF.CNRI.Reston.VA.US id aa00735;
30 Sep 96 5:06 EDT
Received: from exchange01.integralis.co.uk (193.128.143.62) by msw.integralis.co.uk
(Integralis SMTPRS 1.5beta2) with SMTP id <B0000003724 at msw.integralis.co.uk>;
Mon, 30 Sep 1996 10:04:11 +0100
Received: by exchange01.integralis.co.uk with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5)
id <01BBAEB6.F21EB440 at exchange01.integralis.co.uk>; Mon, 30 Sep 1996 10:05:45 +0100
Message-Id: <c=GB%a=_%p=Quza%l=EXCHANGE01-960930090544Z-98 at exchange01.integralis.co.uk>
Sender:ietf-request at ietf.org
From: Kevin Washburn <Kevin.Washburn at quza.com>
To: "'ietf at IETF.CNRI.reston.VA.US'" <ietf at IETF.CNRI.Reston.VA.US>
Subject:
Date: Mon, 30 Sep 1996 10:05:44 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
unsubscribe ietf kevin.washburn at integralis.co.uk
unsubscribe ietf-announce kevin.washburn at integralis.co.uk
unsubscribe ietf kevin_washburn at integralis.co.uk
unsubscribe ietf-announce kevin_washburn at integralis.co.uk
Received: from ietf.org by ietf.org id aa05044; 30 Sep 96 8:02 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa04846; 30 Sep 96 7:58 EDT
Received: from JCDBS.ITSI.DISA.MIL by IETF.CNRI.Reston.VA.US id aa00839;
30 Sep 96 7:58 EDT
Received: from SMTPLink-Logicon.itsi.disa.mil (SMTPLink-Logicon.itsi.disa.mil [192.234.182.8]) by jcdbs.itsi.disa.mil (8.7.5/8.7.1) with SMTP id HAA09500; Mon, 30 Sep 1996 07:53:42 -0400 (EDT)
Sender:ietf-request at ietf.org
From: Jason_Canon_at_LOGICON.LC2 at itsi.disa.mil
Received: from ccMail by SMTPLink-Logicon.itsi.disa.mil (SMTPLINK V2.11 PreRelease 4)
id AA844095275; Sun, 29 Sep 96 19:54:17 EST
Date: Sun, 29 Sep 96 19:54:17 EST
Encoding: 68 Text
Message-Id: <9608308440.AA844095275 at SMTPLink-Logicon.itsi.disa.mil>
To: dwm at shell.portal.com, "Carl Malamud [IMS]" <carl at media.org>
Cc: bob at mindspring.com, ietf at IETF.CNRI.Reston.VA.US
Subject: Re[2]: one example of e-mail abuse commercialized
Source-Info: From (or Sender) name not authenticated.
Any chance that someone will voluntarily create a mailing list, or
newsgroup, to discuss spam issues that is not directed to IETF
subscribers? In one sense the discussion of spam issues is spam to
IETF subscribers eh? If such a list is created it might be helpful to
invite those sending spam messages to join the discussion and present
their views. There are already too many "spam vigilantes" and little
if any constructive dialog taking place.
Thank you.
______________________________ Reply Separator _________________________________
Subject: Re: one example of e-mail abuse commercialized
Author: "Carl Malamud [IMS]" <carl at media.org> at SMTPLink-Logicon
Date: 9/29/96 9:11 PM
I don't think you've been listening to what Bob Morris from
Mindspring has been saying. PSI's service is under new
management and it sure sounds like the new owners are taking
an agressive stand on spam.
I certainly deplore PSI's lack of community spirit, and I
think that is just one of the reasons they found themselves
unable to run a successful service for end users. Perhaps
it makes sense to give the new owners a chance?
Carl
According to David W. Morris:
>
>
>
> On Sun, 29 Sep 1996, Bob McNamara wrote:
>
> > At 12:54 PM 9/29/96 -0700, you wrote:
> > >
> > >
> > >On Sun, 29 Sep 1996, Mark Crispin wrote:
> > >I must agree with Mark ... PSI will only start taking this seriously when
> > >their customers leave because they spamming impacts them directly and this
> > >is the only way recipients have today to make spamming cost the sender
> > >more than the recipient. If mindspring doesn't like the association with
> > >PSI then mindspring can find a new provider.
> > >
> > >Dave Morris
> >
> > I don't think you understand.
>
> What I understood what that your company's business would be impacted by
> blocking of PSI's class-A address ... my basic points were and remain:
>
> 1. Anything which forces ISPs such as PSI to be more responsible need to
> be done ... only if their customers walk will they change their
> policies
> 2. If your company was tarred by association with PSIs class-A address,
> they you should find a new ISP.
>
> I understood your different business practices as perhaps helping and was
> not suggesting your approach was wrong, only that if you cared about
> Mark's blocking your customers you should find a new connection to
> the Internet.
>
> There will be less breakage to the overall Internet by blocking traffic
> from individual networks than caused by the spamming.
>
> Dave Morris
>
Received: from ietf.org by ietf.org id aa08613; 30 Sep 96 11:18 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa08487;
30 Sep 96 11:12 EDT
Received: from seawind.bellcore.com by IETF.CNRI.Reston.VA.US id aa01018;
30 Sep 96 11:12 EDT
Received: (from huitema at localhost) by seawind.bellcore.com (8.6.9/8.6.10) id LAA08676; Mon, 30 Sep 1996 11:09:14 -0400
Date: Mon, 30 Sep 1996 11:09:14 -0400
Sender:ietf-request at ietf.org
From: Christian Huitema <huitema at bellcore.com>
Message-Id: <9609301109.ZM8674 at seawind.bellcore.com>
In-Reply-To: Jason_Canon_at_LOGICON.LC2 at itsi.disa.mil
"Re[2]: one example of e-mail abuse commercialized" (Sep 29, 7:54pm)
References: <9608308440.AA844095275 at SMTPLink-Logicon.itsi.disa.mil>
X-Mailer: Z-Mail (3.2.0 06sep94)
To: Jason_Canon_at_LOGICON.LC2 at itsi.disa.mil, dwm at shell.portal.com,
"Carl Malamud [IMS]" <carl at media.org>
Subject: Re: Re[2]: one example of e-mail abuse commercialized
Cc: bob at mindspring.com, ietf at IETF.CNRI.Reston.VA.US
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
I believe that the engineering of "spamming detection" and "spamming
blocking" devices is a perfectly valid IETF work topic. But then, we
should be discussing engineering, not philosophy. A brief summary:
1) spamming is a nuisance. Advertisers have plenty of resources to make
their products known on the Internet without resorting to it.
2) existing tools are not very adequate. For example, I block spamming to
my mail box with a variety of mail filters, but maintaining them is
cumbersome. Blocking whole provider sites, let alone whole networks, can
very well be overkill.
3) spamming detction, on the other hand, is quite doable. It has been done
for news services, and the same solution can be applied to e-mail. The
basic idea is to detect that someone is starting to send tons of copies of
the same message, then automatically instruct mailers to file these
messages to the appropriate bit sink.
4) unlike news, spamming cannot be prevented by a single site. We need a
network of sites, that reacts defensilvely. When a suspect pattern is
detected, further analysis is taken. Once the spamming is confirmed, the
information has to be passed to all sites in the network, to warn them of
the incoming spam.
The warning mecanisms, the process by which you distribute the knowledge
to site members, and the precise way you can terminate a message without
causing grief are natural work topics for the IETf. Anyone wants to convey
a BOF in San Jose ?
--
Christian Huitema
Received: from ietf.org by ietf.org id aa09300; 30 Sep 96 11:40 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa09204;
30 Sep 96 11:37 EDT
Received: from atlas.xylogics.com by IETF.CNRI.Reston.VA.US id aa01054;
30 Sep 96 11:37 EDT
Received: from huey.xylogics.com (huey.xylogics.com [132.245.32.139]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id LAA09239; Mon, 30 Sep 1996 11:36:07 -0400 (EDT)
Received: by huey.xylogics.com id AA02034 (4.1/UK-doug-951219);
Mon, 30 Sep 96 11:36:12 EDT
Sender:ietf-request at ietf.org
From: Gary Scott Malkin <gmalkin at xylogics.com>
Date: Mon, 30 Sep 96 11:36:12 EDT
Message-Id: <2034.9609301536 at huey.xylogics.com>
To: andyni at microsoft.com
Cc: ietf at IETF.CNRI.Reston.VA.US, ALLOCCHIO at elettra.trieste.it,
pint001 at it.net
In-Reply-To: Andrew Nicholson's message of Sat, 28 Sep 1996 16:03:52 -0700 <c=US%a=_%p=msft%l=RED-71-MSG-960928230352Z-14916 at mail3.microsoft.com>
Subject: one example of e-mail abuse commercialized
Source-Info: From (or Sender) name not authenticated.
> The only solution will be to create a cost recapture mechanism which
> burdens the sender with the cost of email rather than the recipient,
> like the postal systems do now.
Hopefully not the same way as the Post Office. I get MUCH MUCH more
junk mail that I do real mail. I get it because the junk mailers
don't pay first class postage on the crap they send (take a look the
next time you get some). I think bulk crap should pay full price.
That would be good for the Post Office (maybe they won't increase
the proce of our mail for a while) and it might cut down on the junk
(which should make the environmentalists happy because most of that
stuff ends up in landfills).
Unfortunately, I don't see any mechanism like this working for the
Internet. I like other suggestions I have seen. Tear the people
who do it off the net. We are not common carrier so we are not
obligated to provide service. I hope we stay that way.
----------------------------------------------------------------------
Gary Malkin Cheap, Fast, Good
(617) 238-6237 Pick two!
Received: from ietf.org by ietf.org id aa10210; 30 Sep 96 12:09 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa10105;
30 Sep 96 12:06 EDT
Received: from nimbus.superior.net by IETF.CNRI.Reston.VA.US id aa01080;
30 Sep 96 12:06 EDT
Received: (from exidor at localhost) by nimbus.superior.net (8.7.6/8.7.5) id MAA11933; Mon, 30 Sep 1996 12:05:40 -0400 (EDT)
Message-Id: <199609301605.MAA11933 at nimbus.superior.net>
Date: Mon, 30 Sep 1996 12:05:40 -0400
Sender:ietf-request at ietf.org
From: Christopher Masto <exidor at superior.net>
To: ietf at IETF.CNRI.Reston.VA.US
Cc: Red Grues List <red-grues-and-spam at masto.com>
Subject: Re: one example of e-mail abuse commercialized
In-Reply-To: <2034.9609301536 at huey.xylogics.com>; from Gary Scott Malkin on Sep 30, 1996 11:36:12 -0400
References: <2034.9609301536 at huey.xylogics.com>
X-Mailer: Mutt 0.45
Mime-Version: 1.0
Source-Info: From (or Sender) name not authenticated.
Gary Scott Malkin writes:
> > The only solution will be to create a cost recapture mechanism which
> > burdens the sender with the cost of email rather than the recipient,
> > like the postal systems do now.
>
> Hopefully not the same way as the Post Office. I get MUCH MUCH more
> junk mail that I do real mail. I get it because the junk mailers
> don't pay first class postage on the crap they send (take a look the
> next time you get some). I think bulk crap should pay full price.
As always, I have to throw in my opinion that simply putting a price
tag on something is not the appropriate way to discourage its use,
particularly when, as in the case of Internet services, they are of
vast benefit to many simply because of the current pricing structure
(or lack thereof). This is much like the "people are using too many
IP addresses, therefore 'they should start charging for them'"
argument. It is based on the false premise that the reason something
costs money is to prevent people from having too much of it. In fact,
the reason something costs money is because it has some value added by
whoever is charging the money for it.
--
/ Christopher Masto \ / Superior Net Services \ / Your vote counts \
| exidor at superior.net | | $24.95/month unlimited use | | Support free speech |
\ Programmer/Tech / \ http://www.superior.net/ / \ HappyNet for all /
Received: from ietf.org by ietf.org id aa10382; 30 Sep 96 12:11 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa10191;
30 Sep 96 12:08 EDT
Received: from triste.psc.edu by IETF.CNRI.Reston.VA.US id aa01087;
30 Sep 96 12:08 EDT
Received: (from rapier at localhost) by triste.psc.edu (8.7.6/8.7.3) id MAA00409; Mon, 30 Sep 1996 12:06:27 -0400 (EDT)
Date: Mon, 30 Sep 1996 12:06:27 -0400 (EDT)
Sender:ietf-request at ietf.org
From: Chris Rapier <rapier at psc.edu>
To: Bob McNamara <bob at mindspring.com>
cc: ietf at IETF.CNRI.Reston.VA.US, Mark Crispin <MRC at panda.com>
Subject: Re: one example of e-mail abuse commercialized
In-Reply-To: <199609291526.LAA03967 at itchy.mindspring.com>
Message-ID: <Pine.NEB.3.91.960930115625.262F-100000 at triste.psc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On the subject of spamming maybe you would like to mention something
about posting to inappropriate mailing lists. Mailing lists like this one...
Chris Rapier
Senior Sysadmin/Cabin Boy 2nd Class
Pittsburgh Supercomputing Center
MI 230B
Received: from ietf.org by ietf.org id aa10412; 30 Sep 96 12:11 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa10250;
30 Sep 96 12:09 EDT
Received: from cs.columbia.edu by IETF.CNRI.Reston.VA.US id aa01092;
30 Sep 96 12:09 EDT
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.7.6/8.6.6) with ESMTP id MAA02676; Mon, 30 Sep 1996 12:08:41 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.7.6/8.6.6) with SMTP id MAA00485; Mon, 30 Sep 1996 12:08:41 -0400 (EDT)
X-Orig-Sender: hgs at cs.columbia.edu
Message-ID: <324FF088.3648 at cs.columbia.edu>
Date: Mon, 30 Sep 1996 12:08:40 -0400
Sender:ietf-request at ietf.org
From: "Henning G. Schulzrinne" <schulzrinne at cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Gary Scott Malkin <gmalkin at xylogics.com>
CC: ietf at IETF.CNRI.Reston.VA.US
Subject: Re: one example of e-mail abuse commercialized
References: <2034.9609301536 at huey.xylogics.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
I very much doubt that any non-discriminatory charging scheme (that does
not attach a higher price to spam bytes than, say, ftp or WWW bytes) can
price bulk email out of the market. Consider that sending a 500 byte
message to 1 million recipients is only equivalent to the bytes
generated by about 20 hours of 64 kb/s telephony, which most companies
have no problem affording. Indeed, since bulk email can be made to ride
in the trough of any time-of-day or congestion-sensitive pricing, it
will always be cheap. (If you want to avoid all the liability and
censorship problems with being a publisher, being a common carrier is
actually a fairly nice position to be in. Even a common carrier doesn't
have to allow their customers to ship bombs or use the telephone network
for harassment.)
Since spam costs at least some receivers, namely those paying by the
hour, direct cash, I'm surprised that there hasn't been a class action
lawsuit by those affected against a sufficiently visible spammer, based
on extending the junk-fax law to the obvious equivalent of email. It
seems that junk faxes that were inundating people with ads for fax paper
and the like seem to have decreased significantly since that law was
passed, even though it is clearly possible for somebody to do this from,
say, Canada or Mexico (assuming they don't have similar laws). I'd
imagine that a single well-publicized law suit with a nice, 6-figure
settlement would at least scare the amateurs. Even threatening to enact
such a law by a friendly legislator could get the operators who are into
email advertising for the long haul to agree to some amount of
self-control and a central "Robinson" list. I'm sure the Direct
Marketing Association would love a few new members...
One possibility of a technical defense is that email MUAs or MTAs will
offer the ability to only allow mail reception from people one has had
voluntary contact with before and ask others to supply a
one-time-password, thus forcing bulk emailers to create individualized
mailings for each of their million targets...
Henning
--
Henning Schulzrinne email: schulzrinne at cs.columbia.edu
Dept. of Computer Science phone: +1 212 939-7042
Columbia University fax: +1 212 666-0140
New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs
Received: from ietf.org by ietf.org id aa10633; 30 Sep 96 12:13 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa10435;
30 Sep 96 12:11 EDT
Received: from triste.psc.edu by IETF.CNRI.Reston.VA.US id aa01101;
30 Sep 96 12:11 EDT
Received: (from rapier at localhost) by triste.psc.edu (8.7.6/8.7.3) id MAA00416; Mon, 30 Sep 1996 12:10:14 -0400 (EDT)
Date: Mon, 30 Sep 1996 12:10:14 -0400 (EDT)
Sender:ietf-request at ietf.org
From: Chris Rapier <rapier at psc.edu>
cc: ietf at IETF.CNRI.Reston.VA.US
Subject: Suggested BOF dealing with Spam Regulation
In-Reply-To: <2034.9609301536 at huey.xylogics.com>
Message-ID: <Pine.NEB.3.91.960930120819.262G-100000 at triste.psc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Regardless of what my previous message may of indicate I do think this is
an interesting subject which the IETF may want to consider addressing. I
propose that we set up a mailing list and organize a BOF for the San Jose
confrence.
I am not sure what the proceedures are for this but I would be more than
happy to help/participate.
Chris Rapier
Senior Sysadmin/Cabin Boy 2nd Class
Pittsburgh Supercomputing Center
MI 230B
Received: from ietf.org by ietf.org id aa13453; 30 Sep 96 13:26 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa13197;
30 Sep 96 13:22 EDT
Received: from rodan.UU.NET by IETF.CNRI.Reston.VA.US id aa01162;
30 Sep 96 13:22 EDT
Received: from sayshell.UU.NET by rodan.UU.NET with SMTP
(peer crosschecked as: sayshell.UU.NET [153.39.249.124])
id QQbjkv29235; Mon, 30 Sep 1996 13:20:40 -0400 (EDT)
Message-Id: <QQbjkv29235.199609301720 at rodan.UU.NET>
X-Mailer: exmh version 1.6.9 8/22/96
To: Gary Scott Malkin <gmalkin at xylogics.com>
cc: andyni at microsoft.com, ietf at IETF.CNRI.Reston.VA.US,
ALLOCCHIO at elettra.trieste.it, pint001 at it.net
Sender:ietf-request at ietf.org
From: "Louis A. Mamakos" <louie at uu.net>
Errors-To: ietf-request at ietf.cnri.reston.va.us
Subject: Re: one example of e-mail abuse commercialized
References: <2034.9609301536 at huey.xylogics.com>
In-reply-to: Your message of "Mon, 30 Sep 1996 11:36:12 EDT."
<2034.9609301536 at huey.xylogics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 30 Sep 1996 13:20:40 -0400
X-Orig-Sender: louie at uu.net
Source-Info: From (or Sender) name not authenticated.
I don't think that charging for sending email is the right answer. You've
now managed to impact the traffic I actually want to receive from people.
No, we can use technology when has been in development for years and
suffering from much standardization effort in the IETF: privacy enhanced
mail - specifically mail with signatures attached. (I'm not referring
specifically to the not-quite-dead-yet PEM effort, PGP or something
else would "work").
If I had the option of refusing, or seperately filing messages which were
unsigned, and the mailing lists I subscribed to could be configured to
accept messages from authentic origins which were on the list, then
I think the scope of the problem would be different.
The problem is that we don't have the tools deployed to support a good
solution to the "SPAM" problem. Somehow charging for it depends on yet
another tool which is not yet available. Besides, who do you charge,
and who gets the money?
Louis Mamakos
Received: from ietf.org by ietf.org id aa14477; 30 Sep 96 13:38 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa14328;
30 Sep 96 13:35 EDT
Received: from [137.155.100.216] by IETF.CNRI.Reston.VA.US id aa01186;
30 Sep 96 13:35 EDT
Received: from morgan.cnu.edu (morgan.cnu.edu [137.155.12.216]) by morgan.cnu.edu (8.7.3/8.6.9) with SMTP id NAA07468; Mon, 30 Sep 1996 13:34:29 -0400 (EDT)
Date: Mon, 30 Sep 1996 13:34:29 -0400 (EDT)
Sender:ietf-request at ietf.org
From: "J. Patrick Narkinsky" <patrick at cnu.edu>
To: "Henning G. Schulzrinne" <schulzrinne at cs.columbia.edu>
cc: Gary Scott Malkin <gmalkin at xylogics.com>, ietf at IETF.CNRI.Reston.VA.US
Subject: Re: one example of e-mail abuse commercialized
In-Reply-To: <324FF088.3648 at cs.columbia.edu>
Message-ID: <Pine.GSO.3.95.960930133247.25186X-100000 at morgan.cnu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 30 Sep 1996, Henning G. Schulzrinne wrote:
> Since spam costs at least some receivers, namely those paying by the
> hour, direct cash, I'm surprised that there hasn't been a class action
> lawsuit by those affected against a sufficiently visible spammer, based
> on extending the junk-fax law to the obvious equivalent of email. It
> seems that junk faxes that were inundating people with ads for fax paper
> and the like seem to have decreased significantly since that law was
> passed, even though it is clearly possible for somebody to do this from,
> say, Canada or Mexico (assuming they don't have similar laws). I'd
> imagine that a single well-publicized law suit with a nice, 6-figure
> settlement would at least scare the amateurs. Even threatening to enact
> such a law by a friendly legislator could get the operators who are into
> email advertising for the long haul to agree to some amount of
> self-control and a central "Robinson" list. I'm sure the Direct
> Marketing Association would love a few new members...
>
This makes a lot of sense -- this is not a technical problem, it's a
social problem. And, speaking as a computer engineer, I'd rather let the
specialists in _SOCIAL_ problems deal with it (namely the
legislators/government)
Regards,
Patrick
---------------------------------------------------------------------------
J. Patrick Narkinsky |
<patrick at cc.cnu.edu> |Over the router, through the bridge,
Comp. Systems Sr. Engineer |past the T1, bounce off MAE-East,
CNU Computer Center | nothing but net.
(804)594-7180 |
---------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa14887; 30 Sep 96 13:43 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa14607;
30 Sep 96 13:41 EDT
Received: from dns.IT.net by IETF.CNRI.Reston.VA.US id aa01198;
30 Sep 96 13:41 EDT
Received: from pint001.pn.itnet.it (~me at pint001.pn.ITnet.it [151.2.28.5]) by dns.it.net (8.6.9/8.6.9) with SMTP id TAA05697; Mon, 30 Sep 1996 19:37:50 +0100
Message-Id: <1.5.4.32.19960930190909.006b4918 at 151.1.1.1>
X-Sender: pint001 at 151.1.1.1
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 30 Sep 1996 20:09:09 +0100
To: "Louis A. Mamakos" <louie at uu.net>,
Gary Scott Malkin <gmalkin at xylogics.com>
Sender:ietf-request at ietf.org
From: Ivan Pintori <pint001 at it.net>
Subject: Re: one example of e-mail abuse commercialized
Cc: andyni at microsoft.com, ietf at IETF.CNRI.Reston.VA.US,
ALLOCCHIO at elettra.trieste.it
Source-Info: From (or Sender) name not authenticated.
At 13.20 30/09/96 -0400, Louis A. Mamakos wrote:
>The problem is that we don't have the tools deployed to support a good
>solution to the "SPAM" problem. Somehow charging for it depends on yet
>another tool which is not yet available. Besides, who do you charge,
>and who gets the money?
True, that is the real problem. Who you charge and what for?
No, we should implement a technical solution. Actually I think that we
should build up a working group on the matter, or at least moving this
discussion on some other mailing list that has to do with SMTP, since IMHO
tecnically there lies the solution.
>
>Louis Mamakos
ivan
Received: from ietf.org by ietf.org id aa15401; 30 Sep 96 13:55 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa15255;
30 Sep 96 13:53 EDT
Received: from atlas.xylogics.com by IETF.CNRI.Reston.VA.US id aa01220;
30 Sep 96 13:53 EDT
Received: from huey.xylogics.com (huey.xylogics.com [132.245.32.139]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id NAA20248; Mon, 30 Sep 1996 13:51:39 -0400 (EDT)
Received: by huey.xylogics.com id AA04141 (4.1/UK-doug-951219);
Mon, 30 Sep 96 13:51:44 EDT
Sender:ietf-request at ietf.org
From: Gary Scott Malkin <gmalkin at xylogics.com>
Date: Mon, 30 Sep 96 13:51:44 EDT
Message-Id: <4141.9609301751 at huey.xylogics.com>
To: patrick at cnu.edu
Cc: schulzrinne at cs.columbia.edu, ietf at IETF.CNRI.Reston.VA.US
In-Reply-To: "J. Patrick Narkinsky"'s message of Mon, 30 Sep 1996 13:34:29 -0400 (EDT) <Pine.GSO.3.95.960930133247.25186X-100000 at morgan.cnu.edu>
Subject: one example of e-mail abuse commercialized
Source-Info: From (or Sender) name not authenticated.
> This makes a lot of sense -- this is not a technical problem, it's a
> social problem. And, speaking as a computer engineer, I'd rather let the
> specialists in _SOCIAL_ problems deal with it (namely the
> legislators/government)
It is more of a social problem than a technical one; however, that
doesn't mean that we can't employ a technical solution. Given the
choice between receiving spam and suffering government intervention,
bring on the spam!
----------------------------------------------------------------------
Gary Malkin Cheap, Fast, Good
(617) 238-6237 Pick two!
Received: from ietf.org by ietf.org id aa15704; 30 Sep 96 14:01 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa15614;
30 Sep 96 13:59 EDT
Received: from callandor.cybercash.com by IETF.CNRI.Reston.VA.US id aa01248;
30 Sep 96 13:59 EDT
Received: by callandor.cybercash.com; id NAA21748; Mon, 30 Sep 1996 13:56:46 -0400
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (V3.1)
id xma021726; Mon, 30 Sep 96 13:56:27 -0400
Received: by cybercash.com (4.1/SMI-4.1)
id AA29680; Mon, 30 Sep 96 13:57:17 EDT
Date: Mon, 30 Sep 1996 13:57:15 -0400 (EDT)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: "Louis A. Mamakos" <louie at uu.net>
Cc: ietf at IETF.CNRI.Reston.VA.US, ietf-muse at imc.org
Subject: Re: one example of e-mail abuse commercialized
In-Reply-To: <QQbjkv29235.199609301720 at rodan.UU.NET>
Message-Id: <Pine.SUN.3.91.960930134617.26875K-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 30 Sep 1996, Louis A. Mamakos wrote:
> Date: Mon, 30 Sep 1996 13:20:40 -0400
> From: Louis A. Mamakos <louie at uu.net>
> To: Gary Scott Malkin <gmalkin at xylogics.com>
> Cc: andyni at microsoft.com, ietf at IETF.CNRI.Reston.VA.US,
> ALLOCCHIO at elettra.trieste.it, pint001 at it.net
> Subject: Re: one example of e-mail abuse commercialized
>
> I don't think that charging for sending email is the right answer. You've
> now managed to impact the traffic I actually want to receive from people.
The idea would be to enable *you* to impose charges such as you wish on
various categories of incoming traffic.
> No, we can use technology when has been in development for years and
> suffering from much standardization effort in the IETF: privacy enhanced
> mail - specifically mail with signatures attached. (I'm not referring
> specifically to the not-quite-dead-yet PEM effort, PGP or something
> else would "work").
Secure identification of senders of mail would be a real benefit. You
would even want this if you also had the charging option since you would
want to securely recognize those you wanted to let in free (probably
including mailing lists you were on).
> If I had the option of refusing, or seperately filing messages which were
> unsigned, and the mailing lists I subscribed to could be configured to
> accept messages from authentic origins which were on the list, then
> I think the scope of the problem would be different.
The problems with widely deploying secure mail have been (1) user agent
migration and (2) key distribution. See draft-eastlake-muse-02.txt. The
MUSE mailing list is ietf-muse at imc.org.
> The problem is that we don't have the tools deployed to support a good
> solution to the "SPAM" problem. Somehow charging for it depends on yet
> another tool which is not yet available. Besides, who do you charge,
> and who gets the money?
Since you would need security first anyway, charging is kind of a long
term solution. There would obviously be lots of problems to work out
but its not impossible. See draft-eastlake-internet-payment-02.txt,
particularly the SMTP section.
> Louis Mamakos
Donald
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from ietf.org by ietf.org id aa16420; 30 Sep 96 14:08 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa16327;
30 Sep 96 14:06 EDT
Received: from atlas.xylogics.com by IETF.CNRI.Reston.VA.US id aa01259;
30 Sep 96 14:05 EDT
Received: from huey.xylogics.com (huey.xylogics.com [132.245.32.139]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id OAA21275; Mon, 30 Sep 1996 14:04:06 -0400 (EDT)
Received: by huey.xylogics.com id AA04252 (4.1/UK-doug-951219);
Mon, 30 Sep 96 14:04:11 EDT
Sender:ietf-request at ietf.org
From: Gary Scott Malkin <gmalkin at xylogics.com>
Date: Mon, 30 Sep 96 14:04:11 EDT
Message-Id: <4252.9609301804 at huey.xylogics.com>
To: Valdis.Kletnieks at vt.edu
Cc: patrick at cnu.edu, schulzrinne at cs.columbia.edu,
ietf at IETF.CNRI.Reston.VA.US
In-Reply-To: Valdis.Kletnieks at vt.edu's message of Mon, 30 Sep 1996 13:54:15 -0400 <199609301754.NAA25212 at black-ice.cc.vt.edu>
Subject: one example of e-mail abuse commercialized
Source-Info: From (or Sender) name not authenticated.
> Do we *really* want to hand the war on spam to them? First thing you'll
> know, some senior congressman will find a way to turn it into pork for
> his home district.
I thought spam was pork ;-)
----------------------------------------------------------------------
Gary Malkin Cheap, Fast, Good
(617) 238-6237 Pick two!
Received: from ietf.org by ietf.org id aa16745; 30 Sep 96 14:15 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa16628;
30 Sep 96 14:13 EDT
Received: from aragorn.alternic.net by IETF.CNRI.Reston.VA.US id aa01270;
30 Sep 96 14:13 EDT
Received: (from ekashp at localhost) by aragorn.alternic.net (8.6.12/8.6.6) id LAA28695; Mon, 30 Sep 1996 11:29:33 -0700
Date: Mon, 30 Sep 1996 11:29:33 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Eugene Kashpureff <ekashp at alternic.net>
To: Jason_Canon_at_LOGICON.LC2 at itsi.disa.mil
cc: ietf at IETF.CNRI.Reston.VA.US, mouse at rodents.montreal.qc.ca
Subject: Re: Re[2]: one example of e-mail abuse commercialized
In-Reply-To: <9608308440.AA844095275 at SMTPLink-Logicon.itsi.disa.mil>
Message-ID: <Pine.LNX.3.91.960930112304.28639E-100000 at aragorn.alternic.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sun, 29 Sep 1996 Jason_Canon_at_LOGICON.LC2 at itsi.disa.mil wrote:
> Any chance that someone will voluntarily create a mailing list, or
> newsgroup, to discuss spam issues that is not directed to IETF
> subscribers? In one sense the discussion of spam issues is spam to
> IETF subscribers eh? If such a list is created it might be helpful to
At the last IETF we held an anti-spam BOF. Last I heard we were
going to petition for an anti-spam WG under user services,
with a heavy emphasis on educating against spam.
> invite those sending spam messages to join the discussion and present
> their views. There are already too many "spam vigilantes" and little
> if any constructive dialog taking place.
As it is, I attended the anti-spam BOF as a reformed spammer,
and strongly encourage any anti-spam group to invite the
participation of spammers.
Mouse, have you been in touch with Chris ?
At your name service,
Eugene Kashpureff, ALTERNIC.NET
Received: from ietf.org by ietf.org id aa17597; 30 Sep 96 14:39 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa17522;
30 Sep 96 14:36 EDT
Received: from tomobiki-cho.cac.washington.edu by IETF.CNRI.Reston.VA.US
id aa01298; 30 Sep 96 14:36 EDT
Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU
(8.7.5/UW-NDC Revision: 2.28 ) id LAA21149; Mon, 30 Sep 1996 11:35:57 -0700 (PDT)
Received: from localhost by Ikkoku-Kan.Panda.COM
(NX5.67e/UW-NDC/Panda Revision: 2.27.MRC ) id AA07294; Mon, 30 Sep 96 11:35:52 -0700
Date: Mon, 30 Sep 1996 10:52:48 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: Re: one example of e-mail abuse commercialized
To: Ivan Pintori <pint001 at it.net>
Cc: "Louis A. Mamakos" <louie at uu.net>,
Gary Scott Malkin <gmalkin at xylogics.com>, andyni at microsoft.com,
ietf at IETF.CNRI.Reston.VA.US, ALLOCCHIO at elettra.trieste.it
In-Reply-To: <1.5.4.32.19960930190909.006b4918 at 151.1.1.1>
Message-Id: <MailManager.844105968.286.mrc at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 30 Sep 1996 20:09:09 +0100, Ivan Pintori wrote:
> No, we should implement a technical solution.
I agree that a technical solution is appropriate, but we need to specify the
requirements of any technical solution before passing it on to some working
group. The burden must be squarely placed on the originator, and not the
recipient, of spam; and this should be in the charter.
It is presumptious and arrogant to suggest that the victims should somehow
configure or patch the incoming mailers on their machine. This responsibility
belongs to those who are in the business of selling IP connectivity; to those
who (presumably unwittingly) sell service to spammers.
It isn't as if the ISPs can't do anything. Earlier this year, AOL was one of
the worst sources of spam; now they are respected for their leadership against
spam. If AOL can accomplish such a turnaround, then so can PSI, NETCOM, and
IBM.NET.
As far as the question of the heavy hand of government, I wish to point out
that the myth of the Internet evolving in anarchy without government control
is just that -- a myth. The Internet evolved under the benevolent, but real,
dictatorial control of the US Department of Defense; under ARPA and later
under DCA. DCA had the power and the will to pull the plug on a site without
notice; but at the same time they permitted remarkable leeway. This style of
management continued under NSF, and finally ended only a few years ago.
Received: from ietf.org by ietf.org id aa20227; 30 Sep 96 15:30 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa19961;
30 Sep 96 15:27 EDT
Received: from triste.psc.edu by IETF.CNRI.Reston.VA.US id aa01343;
30 Sep 96 15:27 EDT
Received: (from rapier at localhost) by triste.psc.edu (8.7.6/8.7.3) id PAA00882; Mon, 30 Sep 1996 15:25:21 -0400 (EDT)
Date: Mon, 30 Sep 1996 15:25:21 -0400 (EDT)
Sender:ietf-request at ietf.org
From: Chris Rapier <rapier at psc.edu>
To: Eugene Kashpureff <ekashp at alternic.net>
cc: Jason_Canon_at_LOGICON.LC2 at itsi.disa.mil, ietf at IETF.CNRI.Reston.VA.US,
mouse at rodents.montreal.qc.ca
Subject: Re: Re[2]: one example of e-mail abuse commercialized
In-Reply-To: <Pine.LNX.3.91.960930112304.28639E-100000 at aragorn.alternic.net>
Message-ID: <Pine.NEB.3.91.960930151233.262Y-100000 at triste.psc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 30 Sep 1996, Eugene Kashpureff wrote:
> At the last IETF we held an anti-spam BOF. Last I heard we were
> going to petition for an anti-spam WG under user services,
> with a heavy emphasis on educating against spam.
Any details on this? I just set up a simple mail list that I was going to
advert on here as a forum for these messages. If one already exists I
don't want to duplicate efforts. If it doens't exist then I can host it.
> As it is, I attended the anti-spam BOF as a reformed spammer,
> and strongly encourage any anti-spam group to invite the
> participation of spammers.
I think participation and dialogue between the spam and anti-spam
factions are important. It is essential for people to understand that
spammers are with us and will be for some time. The medium of e-mail is
just too lucrative to pass up. However, if the results of their actions
can be controlled we can change them from being a major nusance into a
minor one.
If there isn't a mailing list dealing with this yet I have set up
spam-list at triste.psc.edu to talk about this. As of yet it is not
automated so send subscription requests and such to
spam-list-request at triste.psc.edu and I'll sign you up.
Chris Rapier
Senior Sysadmin/Cabin Boy 2nd Class
Pittsburgh Supercomputing Center
MI 230B
Received: from ietf.org by ietf.org id aa20788; 30 Sep 96 15:48 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa20693;
30 Sep 96 15:46 EDT
Received: from dns.IT.net by IETF.CNRI.Reston.VA.US id aa01355;
30 Sep 96 15:46 EDT
Received: from pint001.pn.itnet.it (~me at pint001.pn.ITnet.it [151.2.28.5]) by dns.it.net (8.6.9/8.6.9) with SMTP id VAA13986; Mon, 30 Sep 1996 21:44:29 +0100
Message-Id: <1.5.4.32.19960930211547.006baff0 at 151.1.1.1>
X-Sender: pint001 at 151.1.1.1
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 30 Sep 1996 22:15:47 +0100
To: Gary Scott Malkin <gmalkin at xylogics.com>, Valdis.Kletnieks at vt.edu
Sender:ietf-request at ietf.org
From: Ivan Pintori <pint001 at it.net>
Subject: Re: one example of e-mail abuse commercialized
Cc: ietf at IETF.CNRI.Reston.VA.US
Source-Info: From (or Sender) name not authenticated.
At 14.04 30/09/96 EDT, Gary Scott Malkin wrote:
>I thought spam was pork ;-)
just about pork... I am quite hungry, and I think I'll go and cook myself
something (just another spam on the internet :)))
ivan
Received: from ietf.org by ietf.org id aa21304; 30 Sep 96 16:04 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa21225;
30 Sep 96 16:02 EDT
Received: from triste.psc.edu by IETF.CNRI.Reston.VA.US id aa01371;
30 Sep 96 16:02 EDT
Received: (from rapier at localhost) by triste.psc.edu (8.7.6/8.7.3) id QAA00989; Mon, 30 Sep 1996 16:01:08 -0400 (EDT)
Date: Mon, 30 Sep 1996 16:01:08 -0400 (EDT)
Sender:ietf-request at ietf.org
From: Chris Rapier <rapier at psc.edu>
To: ietf at IETF.CNRI.Reston.VA.US
Subject: Anti-Spam BOF Mail List
In-Reply-To: <199609301905.PAA22518 at black-ice.cc.vt.edu>
Message-ID: <Pine.NEB.3.91.960930155727.262f-100000 at triste.psc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
I've decided to take some initiative and set up a real mailing list for
the discussion on spamming. I would like to see us take some sort of
action at the next IETF and maybe get some rough ideas about what is
and/or isn't possible in dealing with this problem.
If you would like to join the mailing list send mail to
majordomo at psc.edu
with
subscribe spam-list [prefered address]
in the body.
If you have any problems subscribing let me know. Also, this mailing list
superceeds the one I set up and announced around an hour ago. Anyone who
has alrteady sent requests to that mailing list will be added to this new
one.
Chris Rapier
Senior Sysadmin/Cabin Boy 2nd Class
Pittsburgh Supercomputing Center
MI 230B
Received: from ietf.org by ietf.org id aa21514; 30 Sep 96 16:10 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa21388;
30 Sep 96 16:07 EDT
Received: from dns.IT.net by IETF.CNRI.Reston.VA.US id aa01379;
30 Sep 96 16:07 EDT
Received: from pint001.pn.itnet.it (pint001.pn.ITnet.it [151.2.28.5]) by dns.it.net (8.6.9/8.6.9) with SMTP id WAA15179; Mon, 30 Sep 1996 22:03:19 +0100
Message-Id: <1.5.4.32.19960930213431.006a0e70 at 151.1.1.1>
X-Sender: pint001 at 151.1.1.1
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 30 Sep 1996 22:34:31 +0100
To: Mark Crispin <MRC at panda.com>
Sender:ietf-request at ietf.org
From: Ivan Pintori <pint001 at it.net>
Subject: Re: one example of e-mail abuse commercialized
Cc: ietf at IETF.CNRI.Reston.VA.US
Source-Info: From (or Sender) name not authenticated.
[I trimmed the CC line just a bit.. it was getting pretty huge :)))]
At 10.52 30/09/96 -0700, Mark Crispin wrote:
>I agree that a technical solution is appropriate, but we need to specify the
>requirements of any technical solution before passing it on to some working
>group. The burden must be squarely placed on the originator, and not the
>recipient, of spam; and this should be in the charter.
I agree on who to "charge" for this.. but maybe we should shift to an
adiacent branch of though: how about defining mail service. This is not a
new idea, and infact this kind of feature is already present on the SMTP
definition.. now what about slamming some key signature in on the mail
routing level? I am just brainstorming here, so take my word with good care,
but there can be a viable solution that could and should be implemented on
the service level, more then on the client side. Actually, since with the
comming of IPv6 most services should get rewarped, let's actualize this
change on that same date. This would give us some time to propose and review
the actual changes, to implement the new version of SendMail and give a firm
date for deployment of change.
Let's not forgive that the time IPv6 come around, MANY things are NOT going
to work anymore and will be substituted, it is a precious time for us to use
for implementing major changes.
ivan
Received: from ietf.org by ietf.org id aa26793; 30 Sep 96 21:01 EDT
Received: from shiva1.cac.washington.edu by ietf.org id aa26682;
30 Sep 96 20:54 EDT
Received: from localhost (torzillo at localhost) by shiva1.cac.washington.edu (8.7.5+UW96.09/8.7.3+UW96.09) with SMTP id RAA03124 for <ietf at ietf.org>; Mon, 30 Sep 1996 17:54:21 -0700
Date: Mon, 30 Sep 1996 17:54:20 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Tony Torzillo <torzillo at cac.washington.edu>
To: ietf at ietf.org
Subject: 3COM MIBS
Message-ID: <Pine.ULT.3.95.960930175336.28960R-100000 at shiva1.cac.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
I'm looking for a private MIB definition for the following device:
3Com LinkBuilder FMS, SW version:3.1
Tony Torzillo
------------------------------------------------------------------------------
Networks and Distributed Computing Internet: torzillo at cac.washington.edu
University of Washington Phone: (206) 543-5128
4545 15th Avenue N.E. JE-20 Fax: (206) 685-4044
Seattle, WA 98105
------------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa27461; 30 Sep 96 21:24 EDT
Received: from anka.mindvision.com by ietf.org id aa27408; 30 Sep 96 21:21 EDT
Received: (from alan at localhost) by anka.mindvision.com (8.6.11/8.6.9) id UAA05950; Mon, 30 Sep 1996 20:21:16 -0500
Message-Id: <199610010121.UAA05950 at anka.mindvision.com>
Subject: Re: 3COM MIBS
To: Tony Torzillo <torzillo at cac.washington.edu>
Date: Mon, 30 Sep 1996 20:21:15 -2900 (CDT)
Cc: ietf at ietf.org
In-Reply-To: <Pine.ULT.3.95.960930175336.28960R-100000 at shiva1.cac.washington.edu> from "Tony Torzillo" at Sep 30, 96 05:54:20 pm
Sender:ietf-request at ietf.org
From: Alan Hannan <alan at mindvision.com>
Reply-To: Alan Hannan <alan at mindvision.com>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 410
Source-Info: From (or Sender) name not authenticated.
Hi Tony,
> I'm looking for a private MIB definition for the following device:
> 3Com LinkBuilder FMS, SW version:3.1
It may be that you can find such a beast at:
ftp.3com.com:/pub/mibs
It may also be that the newsgroup comp.protocols.snmp would be
more helpful in the future.
Good luck,
Alan
--
Alan Hannan
Not Employed Networking, Ltd.
email: alan at mindvision.com.
phone: 402/488-0238
Received: from ietf.org by ietf.org id aa05727; 1 Oct 96 0:07 EDT
Received: from shiva1.cac.washington.edu by ietf.org id aa05602;
1 Oct 96 0:02 EDT
Received: from localhost (torzillo at localhost) by shiva1.cac.washington.edu (8.7.5+UW96.09/8.7.3+UW96.09) with SMTP id SAA04381; Mon, 30 Sep 1996 18:38:30 -0700
Date: Mon, 30 Sep 1996 18:38:29 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Tony Torzillo <torzillo at cac.washington.edu>
To: Alan Hannan <alan at mindvision.com>
cc: ietf at ietf.org
Subject: Re: 3COM MIBS
In-Reply-To: <199610010121.UAA05950 at anka.mindvision.com>
Message-ID: <Pine.ULT.3.95.960930183547.28960X-100000 at shiva1.cac.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Alan,
Thanks, your tipoff allowed me to find the information I needed on their
ftp server. I was made aware that this was not the appropriate list to
send such a request to so I sincerely appreciate your response. Apologies
to anyone who thought it was an inappropriate post.
Tony Torzillo
On Mon, 30 Sep 1996, Alan Hannan wrote:
>
> Hi Tony,
>
> > I'm looking for a private MIB definition for the following device:
>
> > 3Com LinkBuilder FMS, SW version:3.1
>
> It may be that you can find such a beast at:
>
>ftp.3com.com:/pub/mibs
>
> It may also be that the newsgroup comp.protocols.snmp would be
> more helpful in the future.
>
> Good luck,
>
> Alan
>
> --
> Alan Hannan
> Not Employed Networking, Ltd.
> email: alan at mindvision.com.
> phone: 402/488-0238
>
Received: from ietf.org by ietf.org id aa07222; 1 Oct 96 1:12 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id ab06970; 1 Oct 96 1:08 EDT
Received: from servo.qualcomm.com by IETF.CNRI.Reston.VA.US id aa00496;
30 Sep 96 23:24 EDT
Received: (from karn at localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id UAA23339; Mon, 30 Sep 1996 20:23:03 -0700 (PDT)
Date: Mon, 30 Sep 1996 20:23:03 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Phil Karn <karn at qualcomm.com>
Message-Id: <199610010323.UAA23339 at servo.qualcomm.com>
To: patrick at cnu.edu
CC: schulzrinne at cs.columbia.edu, gmalkin at xylogics.com,
ietf at IETF.CNRI.Reston.VA.US
In-reply-to: <Pine.GSO.3.95.960930133247.25186X-100000 at morgan.cnu.edu> (patrick at cnu.edu)
Subject: Re: one example of e-mail abuse commercialized
Source-Info: From (or Sender) name not authenticated.
>This makes a lot of sense -- this is not a technical problem, it's a
>social problem. And, speaking as a computer engineer, I'd rather let the
>specialists in _SOCIAL_ problems deal with it (namely the
>legislators/government)
I disagree strongly. You can count on them to "solve" the problem in a
way that you won't like at all!
We need technical mechanisms to deal with spam, and I'm convinced that
they can be built. They won't completely solve the problem, but
they'll do an adequate job, much better than any heavy-handed
government-imposed "solution".
Phil
Received: from ietf.org by ietf.org id aa07220; 1 Oct 96 1:12 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa06970; 1 Oct 96 1:08 EDT
Received: from mage.qualcomm.com by IETF.CNRI.Reston.VA.US id aa01631;
30 Sep 96 21:57 EDT
Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by mage.qualcomm.com (8.7.5/1.3/8.7.2/1.12) with ESMTP id SAA13772; Mon, 30 Sep 1996 18:55:57 -0700 (PDT)
X-Sender: jwn2 at mage.qualcomm.com
Message-Id: <v0301030dae7627f6cec9 at [129.46.166.223]>
In-Reply-To: <Pine.NEB.3.91.960930155727.262f-100000 at triste.psc.edu>
References: <199609301905.PAA22518 at black-ice.cc.vt.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Eudora [Macintosh version 3.0.1a3-10.96]
X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57
Date: Mon, 30 Sep 1996 18:53:34 -0700
To: Chris Rapier <rapier at psc.edu>, ietf at IETF.CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
Subject: Re: Anti-Spam BOF Mail List
Source-Info: From (or Sender) name not authenticated.
At 4:01 PM -0400 9/30/96, Chris Rapier wrote:
>I've decided to take some initiative and set up a real mailing list for
>the discussion on spamming. I would like to see us take some sort of
>action at the next IETF and maybe get some rough ideas about what is
>and/or isn't possible in dealing with this problem.
>
Thank you, Chris!
I think it is ironic that spam seem to generate more pro or con-spam than
spam itself. :-)
All things considered, I'd prefer to see a future where the ratio of
spam::non-spam remains low. But working out how to reach that future on
ietf at ietf.cnri.reston.va.us is probably not the best way to go about it.
An Anti-Spam mailing list & BOF is a wonderful idea!
best,
john noerenberg
jwn2 at qualcomm.com
noerenberg.j (Applelink)
----------------------------------------------------------------------
Lemme explain....no, there is too much. Lemme sum up.
Indigo Montoya, "The Princess Bride", Columbia 1987
----------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa07278; 1 Oct 96 1:13 EDT
Received: from cnri by ietf.org id af07062; 1 Oct 96 1:11 EDT
Received: from gw.home.vix.com by CNRI.Reston.VA.US id aa25495;
30 Sep 96 23:05 EDT
Received: by gw.home.vix.com id UAA22116; Mon, 30 Sep 1996 20:04:44 -0700 (PDT)
Date: Mon, 30 Sep 1996 20:04:44 -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: Anti-Spam BOF Mail List
Organization: Vixie Enterprises
Message-ID: <VIXIE.96Sep30200442 at wisdom.vix.com>
References: <199609301905.PAA22518 at black-ice.cc.vt.edu>
BAD MSG:
<Pine.NEB.3.91.960930155727.262f-100000 at triste.psc.edu>
NTP-Posting-Host: wisdom.home.vix.com
In-reply-to: rapier at psc.edu's message of 30 Sep 1996 13:23:41 -0700
Xref: vixie local.mail.net.ietf:6180
Source-Info: From (or Sender) name not authenticated.
Oh good, another anti-spam list. (Hint: a lot of folks are working on this
already.)
Oh good, another BOF. (Hint: hard technical topics have trouble getting
BOF space any more since there aren't enough days in the IETF schedule.)
--
Paul Vixie
La Honda, CA"Illegitimibus non carborundum."
<paul at vix.com>
pacbell!vixie!paul
Received: from ietf.org by ietf.org id aa13792; 1 Oct 96 8:15 EDT
Received: from callandor.cybercash.com by ietf.org id aa13661; 1 Oct 96 8:08 EDT
Received: by callandor.cybercash.com; id IAA21946; Tue, 1 Oct 1996 08:04:36 -0400
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (V3.1)
id xma021938; Tue, 1 Oct 96 08:04:18 -0400
Received: by cybercash.com (4.1/SMI-4.1)
id AA16922; Tue, 1 Oct 96 08:05:08 EDT
Date: Tue, 1 Oct 1996 08:05:07 -0400 (EDT)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: ietf at ietf.org
Cc: spam-list at psc.edu
Subject: Spam lists, boycott
In-Reply-To: <1.5.4.32.19960930213431.006a0e70 at 151.1.1.1>
Message-Id: <Pine.SUN.3.91.960930182803.5658D-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
I suggest that further technical disucssion be moved to the
spam-list at psc.edu mailing list.
IETFers may be interested in knowing that a Boycott Spam campaign is
being planned. The mailing list for this campaign is
spam at zorch.sf-bay.org and a draft web page is at http://www.wvu.com/spam/
This web page will be moved to a more permanent home and the campaign
publicly announced probably within a day or two.
Donald
PS: responding to the message below:
Better security on SMTP connections and better email security can help.
But I don't believe there is going to be any flag day when IPV6 takes
over. In fact, I fully extpect there to be multinational IPv4
connectivity for at least the next ten years. So solutions can't be
attached to an IPv6 takeover.
On Mon, 30 Sep 1996, Ivan Pintori wrote:
> Date: Mon, 30 Sep 1996 22:34:31 +0100
> From: Ivan Pintori <pint001 at it.net>
> To: Mark Crispin <MRC at panda.com>
> Cc: ietf at IETF.CNRI.Reston.VA.US
> Subject: Re: one example of e-mail abuse commercialized
>
> [I trimmed the CC line just a bit.. it was getting pretty huge :)))]
>
> At 10.52 30/09/96 -0700, Mark Crispin wrote:
> >I agree that a technical solution is appropriate, but we need to specify the
> >requirements of any technical solution before passing it on to some working
> >group. The burden must be squarely placed on the originator, and not the
> >recipient, of spam; and this should be in the charter.
>
> I agree on who to "charge" for this.. but maybe we should shift to an
> adiacent branch of though: how about defining mail service. This is not a
> new idea, and infact this kind of feature is already present on the SMTP
> definition.. now what about slamming some key signature in on the mail
> routing level? I am just brainstorming here, so take my word with good care,
> but there can be a viable solution that could and should be implemented on
> the service level, more then on the client side. Actually, since with the
> comming of IPv6 most services should get rewarped, let's actualize this
> change on that same date. This would give us some time to propose and review
> the actual changes, to implement the new version of SendMail and give a firm
> date for deployment of change.
>
> Let's not forgive that the time IPv6 come around, MANY things are NOT going
> to work anymore and will be substituted, it is a precious time for us to use
> for implementing major changes.
>
> ivan
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from ietf.org by ietf.org id aa15449; 1 Oct 96 9:27 EDT
Received: from dxmint.cern.ch by ietf.org id aa15337; 1 Oct 96 9:22 EDT
Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch
with SMTP id PAA10785; Tue, 1 Oct 1996 15:21:20 +0200 (MET DST)
Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM)
id AA23334; Tue, 1 Oct 1996 15:21:19 +0200
Message-Id: <9610011321.AA23334 at dxcoms.cern.ch>
Subject: Re: Spam lists, boycott
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
Date: Tue, 1 Oct 1996 15:21:19 +0200 (MET DST)
Sender:ietf-request at ietf.org
From: Brian Carpenter CERN-CN <brian at dxcoms.cern.ch>
Cc: ietf at ietf.org, spam-list at psc.edu
In-Reply-To: <Pine.SUN.3.91.960930182803.5658D-100000 at cybercash.com> from "Donald E. Eastlake 3rd" at Oct 1, 96 08:05:07 am
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
> But I don't believe there is going to be any flag day when IPV6 takes
> over. In fact, I fully extpect there to be multinational IPv4
> connectivity for at least the next ten years. So solutions can't be
> attached to an IPv6 takeover.
>
Sure. In any case, there is no reason to modify SMTP
for IPv6. There is one RFC 822 address format to be
reviewed, but nothing fundamental. Anti-spam is a completely
different level of problem.
Brian Carpenter
Received: from ietf.org by ietf.org id aa15621; 1 Oct 96 9:31 EDT
Received: from localhost by ietf.org id aa15527; 1 Oct 96 9:27 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: trunk-mib at cisco.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-trunkmib-ds0-mib-03.txt
Date: Tue, 01 Oct 1996 09:27:52 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610010927.aa15527 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 DS1/DS3 MIB Working Group of
the IETF.
Title : Definitions of Managed Objects for the DS0 and DS0
Bundle Interface Type
Author(s) : D. Fowler
Filename : draft-ietf-trunkmib-ds0-mib-03.txt
Pages : 20
Date : 09/26/1996
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for managing DS0 and
DS0 Bundle interfaces. This document is a companion document with
Definitions of Managed Objects for the DS1/E1/DS2/E2, DS3/E3 and SONET/SDH
Interface Types, rfcTBD [6], rfcTBD [7] and rfc1595 [8].
This memo specifies a MIB module in a manner that is both compliant to the
SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
This memo does not specify a standard for the Internet community.
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-trunkmib-ds0-mib-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-trunkmib-ds0-mib-03.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za
o Europe
Address: nic.nordu.net
Address: ftp.nis.garr.it
o Pacific Rim
Address: munnari.oz.au
o US East Coast
Address: ds.internic.net
o US West Coast
Address: ftp.isi.edu
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-trunkmib-ds0-mib-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: <19960926141956.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-trunkmib-ds0-mib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-trunkmib-ds0-mib-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960926141956.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16251; 1 Oct 96 9:40 EDT
Received: from localhost by ietf.org id aa15561; 1 Oct 96 9:28 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: trunk-mib at cisco.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-trunkmib-ds3-mib-03.txt
Date: Tue, 01 Oct 1996 09:28:00 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610010928.aa15561 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 DS1/DS3 MIB Working Group of
the IETF.
Title : Definitions of Managed Objects for the
DS3/E3 Interface Type
Author(s) : D. Fowler
Filename : draft-ietf-trunkmib-ds3-mib-03.txt
Pages : 63
Date : 09/26/1996
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for managing DS3 and
E3 interfaces. This document is a companion document with Definitions of
Managed Objects for the DS0, DS1/E1/DS2/E2 and SONET/SDH Interface Types,
rfcTBD [14], rfcTBD [6] and rfcTBD [7].
This memo specifies a MIB module in a manner that is both compliant to the
SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
This memo does not specify a standard for the Internet community.
This document entirely replaces RFC 1407.
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-trunkmib-ds3-mib-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-trunkmib-ds3-mib-03.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za
o Europe
Address: nic.nordu.net
Address: ftp.nis.garr.it
o Pacific Rim
Address: munnari.oz.au
o US East Coast
Address: ds.internic.net
o US West Coast
Address: ftp.isi.edu
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-trunkmib-ds3-mib-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: <19960926144429.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-trunkmib-ds3-mib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-trunkmib-ds3-mib-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960926144429.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16247; 1 Oct 96 9:40 EDT
Received: from localhost by ietf.org id aa15544; 1 Oct 96 9:28 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: trunk-mib at cisco.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-trunkmib-ds1-mib-04.txt
Date: Tue, 01 Oct 1996 09:27:57 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610010928.aa15544 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 DS1/DS3 MIB Working Group of
the IETF.
Title : Definitions of Managed Objects for the DS1, E1, DS2 and
E2 Interface Types
Author(s) : D. Fowler
Filename : draft-ietf-trunkmib-ds1-mib-04.txt
Pages : 77
Date : 09/26/1996
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for managing DS1, E1,
DS2 and E2 interfaces. This document is a companion document with
Definitions of Managed Objects for the DS0, DS3/E3 and SONET/SDH Interface
Types, rfcTBD [19], rfcTBD [17] and rfcTBD [18].
This memo specifies a MIB module in a manner that is both compliant to the
SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
This memo does not specify a standard for the Internet community.
!This document entirely replaces RFC 1406.
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-trunkmib-ds1-mib-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-trunkmib-ds1-mib-04.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za
o Europe
Address: nic.nordu.net
Address: ftp.nis.garr.it
o Pacific Rim
Address: munnari.oz.au
o US East Coast
Address: ds.internic.net
o US West Coast
Address: ftp.isi.edu
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-trunkmib-ds1-mib-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: <19960926143846.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-trunkmib-ds1-mib-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-trunkmib-ds1-mib-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960926143846.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17173; 1 Oct 96 9:56 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa16856; 1 Oct 96 9:53 EDT
Received: from ftp.com by IETF.CNRI.Reston.VA.US id aa00956; 1 Oct 96 9:53 EDT
Received: from ftp.com by ftp.com ; Tue, 1 Oct 1996 09:51:58 -0400
Received: from mailserv-2high.ftp.com by ftp.com ; Tue, 1 Oct 1996 09:51:58 -0400
Received: from erussell-1.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4)
id JAA21540; Tue, 1 Oct 1996 09:51:51 -0400
Message-Id: <199610011351.JAA21540 at MAILSERV-2HIGH.FTP.COM>
X-Mapi-Messageclass: IPM
Priority: Normal
To: dee at cybercash.com, louie at uu.net
Cc: ietf at IETF.CNRI.Reston.VA.US, ietf-muse at imc.org
X-Mailer: FTP Software Internet Mail 2.0
Mime-Version: 1.0
Sender:ietf-request at ietf.org
From: Edward Russell <erussell at ftp.com>
X-Orig-Sender: Edward Russell <erussell at ftp.com>
Subject: RE: one example of e-mail abuse commercialized
Date: Tue, 01 Oct 1996 09:51:19 -0400
Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Donald E. Eastlake 3rd (dee at cybercash.com) said on 9/30/96
-The idea would be to enable *you* to impose charges such as you wish on
-various categories of incoming traffic.
-
THIS IS AN AUTOMATICALLY GENERATED BILLING NOTICE
My mail server has received a mail item from you.
Due to the increasing volume of mail which people expect me to download, store,
and read, I have decided to start charging for received mail.
I have not yet read your mail item nor will I till I receive payment of 1 cent per
word. This nominal fee will cover my reading time and costs of disk storage.
If you choose not to pay this postage fee, my mail server will automatically delete your
mail item, unread, after 24 hours. That is certainly your option. Note, you may
choose to pay me to download only half of the words in your message, but some
content may be lost and you might be wasting your money.
Ask me about monthly based, "All I can read", charge accounts.
Thank you.
END OF AUTOMATICALLY GENERATED BILLING NOTICE
Received: from ietf.org by ietf.org id aa19477; 1 Oct 96 10:33 EDT
Received: from callandor.cybercash.com by ietf.org id aa19378;
1 Oct 96 10:30 EDT
Received: by callandor.cybercash.com; id KAA29752; Tue, 1 Oct 1996 10:27:42 -0400
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (V3.1)
id xma029740; Tue, 1 Oct 96 10:27:16 -0400
Received: by cybercash.com (4.1/SMI-4.1)
id AA20562; Tue, 1 Oct 96 10:28:08 EDT
Date: Tue, 1 Oct 1996 10:28:08 -0400 (EDT)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: ietf at ietf.org
Subject: boycott spam URL
Message-Id: <Pine.SUN.3.91.961001102715.18546E-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
My apologies, I typoed one character in this in my previous message, it's
http://zorch.wvs.com/spam/
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from ietf.org by ietf.org id aa19475; 1 Oct 96 10:33 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa19175; 1 Oct 96 10:28 EDT
Received: from callandor.cybercash.com by IETF.CNRI.Reston.VA.US id aa00992;
1 Oct 96 10:28 EDT
Received: by callandor.cybercash.com; id KAA29669; Tue, 1 Oct 1996 10:25:12 -0400
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (V3.1)
id xma029657; Tue, 1 Oct 96 10:25:08 -0400
Received: by cybercash.com (4.1/SMI-4.1)
id AA20516; Tue, 1 Oct 96 10:26:00 EDT
Date: Tue, 1 Oct 1996 10:25:59 -0400 (EDT)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: Edward Russell <erussell at ftp.com>
Cc: louie at uu.net, ietf at IETF.CNRI.Reston.VA.US, spam-list at psc.edu
Subject: RE: one example of e-mail abuse commercialized
In-Reply-To: <199610011351.JAA21540 at MAILSERV-2HIGH.FTP.COM>
Message-Id: <Pine.SUN.3.91.961001101127.18546D-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
I'm replying to Mr. Russell's joke just to be sure that people *don't*
think the optional ability to impose such charges would be anthing like the
example he gives.
In particular, if some system wished to impose charges, it would be done at
the SMTP level and the mail would never actually be accepted or take up any
disk space on the destination system if the sending system didn't
understand about payment or didn't want to pay. There certainly wouldn't be
yet another piece of "billing" mail generated to further clog things up. If
you want to understand the capabilities I am suggested could be implemented,
see draft-eastlake-internet-payment-02.txt. Certainly, for a practical
system, you would need provision to accept mail free from designated people,
mailing lists, etc. (By the way, this would probably solve the false
subscription problem as well. If you were charging and you didn't add a
mailing list to your free list and someome forged a subscription from you,
the mail would fail. List manager software would probably be quickly adopted
to drop addresses under such circumstances.)
In any case, I don't think it will be practical until there is improved
security.
Spam is a problem because it is so cheap to send. Imposing just a 6 cent
charge on mail from people not on your free list would make sending spam
one hundred times more expensive than it is now!
Donald
On Tue, 1 Oct 1996, Edward Russell wrote:
> Date: Tue, 01 Oct 1996 09:51:19 -0400
> From: Edward Russell <erussell at ftp.com>
> To: dee at cybercash.com, louie at uu.net
> Cc: ietf at IETF.CNRI.Reston.VA.US, ietf-muse at imc.org
> Subject: RE: one example of e-mail abuse commercialized
>
> Donald E. Eastlake 3rd (dee at cybercash.com) said on 9/30/96
>
> -The idea would be to enable *you* to impose charges such as you wish on
> -various categories of incoming traffic.
> -
> THIS IS AN AUTOMATICALLY GENERATED BILLING NOTICE
>
> My mail server has received a mail item from you.
>
> Due to the increasing volume of mail which people expect me to download, store,
> and read, I have decided to start charging for received mail.
> I have not yet read your mail item nor will I till I receive payment of 1 cent per
> word. This nominal fee will cover my reading time and costs of disk storage.
>
> If you choose not to pay this postage fee, my mail server will automatically delete your
> mail item, unread, after 24 hours. That is certainly your option. Note, you may
> choose to pay me to download only half of the words in your message, but some
> content may be lost and you might be wasting your money.
>
> Ask me about monthly based, "All I can read", charge accounts.
>
>
> Thank you.
>
>
> END OF AUTOMATICALLY GENERATED BILLING NOTICE
>
>
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from cnri by ietf.org id aa20296; 1 Oct 96 11:03 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23489;
1 Oct 96 11:03 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <OAA06217 at pad-thai.cam.ov.com>; Tue, 1 Oct 1996 14:02:45 GMT
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA23394; Tue, 1 Oct 96 10:02:36 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <OAA06212 at pad-thai.cam.ov.com>; Tue, 1 Oct 1996 14:02:33 GMT
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id KAA01687; Tue, 1 Oct 1996 10:02:27 -0400
Message-Id: <199610011402.KAA01687 at winkl.cam.ov.com>
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Cc: Martin.Rex at sap-ag.de, cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: gss_context_time()==CREDENTIALS_EXPIRED
In-Reply-To: Your message of "Fri, 27 Sep 1996 14:15:20 EDT."
<9609271815.AA24306 at dcl.MIT.EDU>
Date: Tue, 01 Oct 1996 10:02:26 -0400
From: John Linn <linn at cam.ov.com>
I'll also vote to deprecate the return of GSS_S_CREDENTIALS_EXPIRED
from context-level calls other than GSS_Init_sec_context() and
GSS_Accept_sec_context(), and from per-message calls.
--jl
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <SAA20744 at pad-thai.cam.ov.com>; Fri, 27 Sep 1996 18:15:52 GMT
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA25023; Fri, 27 Sep 96 14:15:32 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA24306; Fri, 27 Sep 1996 14:15:20 -0400
Date: Fri, 27 Sep 1996 14:15:20 -0400
Message-Id: <9609271815.AA24306 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at MIT.EDU>
To: Martin.Rex at sap-ag.de
Cc: cat-ietf at MIT.EDU
In-Reply-To: Martin Rex's message of Fri, 27 Sep 1996 00:27:46 +0200 (MESZ),
<199609262227.AA08405 at sap-ag.de>
Subject: Re: gss_context_time()==CREDENTIALS_EXPIRED
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
From: Martin Rex <martin.rex at sap-ag.de>
Date: Fri, 27 Sep 1996 00:27:46 +0200 (MESZ)
Personally I'd like to see the return code GSS_S_CREDENTIALS_EXPIRED
being deprecated for all calls that do not reference credentials
context_time/wrap/unwrap/getmic/verifymic for GSSAPI v2 and I would
appreciate a hint for implementors how it was intended to be used and
how it is used in V1, and how it SHOULD NOT be used...
Agreed. All aside from the question of whether or not contexts should
expire when the credentials do (which we have settled, although
personally I would preferred if we had settled it the other way), there
is a GSS_S_CONTEXT_EXPIRED error code, and there's no reason for
gss_wrap/unwrap/etc. to return GSS_S_CREDENTIALS_EXPIRED.
- Ted
Received: from ietf.org by ietf.org id aa20974; 1 Oct 96 11:26 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa20852; 1 Oct 96 11:21 EDT
Received: from ftp.com by IETF.CNRI.Reston.VA.US id aa01092; 1 Oct 96 11:21 EDT
Received: from ftp.com by ftp.com ; Tue, 1 Oct 1996 11:20:27 -0400
Received: from mailserv-2high.ftp.com by ftp.com ; Tue, 1 Oct 1996 11:20:27 -0400
Received: from erussell-1.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4)
id LAA00674; Tue, 1 Oct 1996 11:20:19 -0400
Message-Id: <199610011520.LAA00674 at MAILSERV-2HIGH.FTP.COM>
X-Mapi-Messageclass: IPM
Priority: Normal
To: dee at cybercash.com, Edward Russell <erussell at ftp.com>
Cc: louie at uu.net, ietf at IETF.CNRI.Reston.VA.US, spam-list at psc.edu
X-Mailer: FTP Software Internet Mail 2.0
Mime-Version: 1.0
Sender:ietf-request at ietf.org
From: Edward Russell <erussell at ftp.com>
X-Orig-Sender: Edward Russell <erussell at ftp.com>
Subject: RE: one example of e-mail abuse commercialized
Date: Tue, 01 Oct 1996 11:19:47 -0400
Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Donald E. Eastlake 3rd (dee at cybercash.com) said on 10/1/96
-I'm replying to Mr. Russell's joke just to be sure that people *don't*
-think the optional ability to impose such charges would be anthing like the
-example he gives.
Thank you for responding kindly. I certainly don't want to dilute your efforts
to promote your draft. It is an interesting concept and you have two fronts
to promote simultaneously. One front is the technological details of how to implement a
fee (or favored users = free) based incoming mail (or any traffic). The other front
is to promote the basic concept that a user could/should be in control of the traffic
they receive. While it seems natural, it is orthogonal to the culture of the internet and
"real" life as well - I currently can't charge anyone for the junk mail or flyers I receive in my
postal mailbox and must dispose of.
I wonder if a first step is to implement your scheme not on an individual level but at a company
level for things like fee based information/document retrieval or faxback. A user sends an e-mail
to a service company requesting something (information, price quotes, database lookup, document,
search, whatever). The cost of that request is handled by charging for the incoming e-mail itself.
Filters on the SMTP level could be configured to look at the subject and if it is something that will
trigger an automatic service and response, then invoke the billing mechansim.
Currently all snail (postal) mail is paid for by the sender, except in the case where they supply a
postcard or return envelope which states that postage will be paid by the addressee. It would be
interesting to include the digital equivelent of a "postage paid" response envelope or coupon. The
soliciter could include a digitially signed ascii block (good for once, multiple, or forever) which when
included in the reply will allow the reply to get through the SMTP server for free (SMTP server configured
to look for this). Of course the signed block includes the responder's e-mail address and the date good
until or number of times allowed (this would require tracking on the server).
Just some ideas to help mitigate any damage I may have done (though I think the part about
"All I can Read" charge accounts was pretty funny).
Received: from ietf.org by ietf.org id aa22292; 1 Oct 96 12:10 EDT
Received: from unknown-1-11.wrs.com by ietf.org id aa22212; 1 Oct 96 12:08 EDT
Received: from loire.wrs.com by mail.wrs.com with SMTP id AA25872
(5.65c/IDA-1.4.4 for <ietf at ietf.org>); Tue, 1 Oct 1996 08:46:43 -0700
Message-Id: <199610011546.AA25872 at mail.wrs.com>
X-Mailer: exmh version 1.6.7 5/3/96
To: ietf at ietf.org
Subject: Is there a list of lists?
Reply-To: gnn at wrs.com
Organization: Wind River Systems; Alameda, CA; USA
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 01 Oct 1996 08:46:42 -0700
Sender:ietf-request at ietf.org
From: George Neville-Neil <gnn at wrs.com>
Source-Info: From (or Sender) name not authenticated.
Hi Folks,
I'd like to know if there is a comprehensive list of the current working
groups and their mailing lists.
Thanks,
George
--
George V. Neville-Neilwork: gnn at wrs.com home:gnn at netcom.com
NIC: GN82
The path of my life is strewn with cowpats from the devil's own satanic
herd!- Edmund Blackadder
Received: from ietf.org by ietf.org id aa24632; 1 Oct 96 13:22 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa24524; 1 Oct 96 13:19 EDT
Received: from nirvana.genesyslab.com by IETF.CNRI.Reston.VA.US id aa01206;
1 Oct 96 13:19 EDT
Received: from giant.genesyslab.com (giant.genesyslab.com [206.86.238.70]) by nirvana.genesyslab.com (8.7.6/8.7.6) with ESMTP id KAA20984; Tue, 1 Oct 1996 10:19:10 -0700 (PDT)
Received: (from egoshin at localhost) by giant.genesyslab.com (8.7.5/8.7.3) id KAA24693; Tue, 1 Oct 1996 10:18:06 -0700 (PDT)
Date: Tue, 1 Oct 1996 10:18:06 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Leonid Egoshin <egoshin at genesyslab.com>
Message-Id: <199610011718.KAA24693 at giant.genesyslab.com>
To: dee at cybercash.com, erussell at ftp.com
Subject: RE: one example of e-mail abuse commercialized
Cc: ietf at IETF.CNRI.Reston.VA.US, louie at uu.net, spam-list at psc.edu
Source-Info: From (or Sender) name not authenticated.
>From: Edward Russell <erussell at ftp.com>
>
>Currently all snail (postal) mail is paid for by the sender, except in the case where they supply a
>postcard or return envelope which states that postage will be paid by the addressee. It would be
>interesting to include the digital equivelent of a "postage paid" response envelope or coupon. The
>soliciter could include a digitially signed ascii block (good for once, multiple, or forever) which when
>included in the reply will allow the reply to get through the SMTP server for free (SMTP server configured
>to look for this). Of course the signed block includes the responder's e-mail address and the date good
>until or number of times allowed (this would require tracking on the server).
One question - how it would work on mail-lists ?
(How much I could pay for this mail - only for one copy or 1000 copies ?
It is not simple question - if only one, then spamer can use it, if 1000 I would
unsubscribe shortly :-)
Second question - what is about citates - is it include in cost ?
(It is also not simple question, you can rememeber many opinions which are
difficult understand without citation of others)
>- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa26117; 1 Oct 96 14:05 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa26029; 1 Oct 96 14:01 EDT
Received: from amun.glenvan.glenayre.com by IETF.CNRI.Reston.VA.US id aa01244;
1 Oct 96 14:01 EDT
Received: from z28.glenvan.glenayre.com.glenvan.glenayre.com by mailhost.glenvan.glenayre.com (SMI-8.6/SMI-SVR4)
id KAA26293; Tue, 1 Oct 1996 10:56:52 -0700
Sender:ietf-request at ietf.org
From: Brijesh Kumar <bkumar at glenayre.com>
Message-Id: <199610011756.KAA26293 at mailhost.glenvan.glenayre.com>
Subject: Re: one example of e-mail abuse commercialized
To: Leonid Egoshin <egoshin at genesyslab.com>
Date: Tue, 1 Oct 1996 10:56:40 -0700 (PDT)
Cc: dee at cybercash.com, erussell at ftp.com, ietf at IETF.CNRI.Reston.VA.US,
louie at uu.net, spam-list at psc.edu
In-Reply-To: <199610011718.KAA24693 at giant.genesyslab.com> from "Leonid Egoshin" at Oct 1, 96 10:18:06 am
Organization: Glenayre R&D Inc.
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Hi all,
Can all concerned please shift this discussion to spam-list at psc.edu
specially set for this purpose?
(I need a mechanism to stop SPAMMING. NOW!).
Thanks,
--brijesh
(Pl. don't respond to me. Thanks.)
>
> >From: Edward Russell <erussell at ftp.com>
> >
> >Currently all snail (postal) mail is paid for by the sender, except in the case where they supply a
> >postcard or return envelope which states that postage will be paid by the addressee. It would be
> >interesting to include the digital equivelent of a "postage paid" response envelope or coupon. The
> >soliciter could include a digitially signed ascii block (good for once, multiple, or forever) which when
> >included in the reply will allow the reply to get through the SMTP server for free (SMTP server configured
> >to look for this). Of course the signed block includes the responder's e-mail address and the date good
> >until or number of times allowed (this would require tracking on the server).
>
> One question - how it would work on mail-lists ?
> (How much I could pay for this mail - only for one copy or 1000 copies ?
> It is not simple question - if only one, then spamer can use it, if 1000 I would
> unsubscribe shortly :-)
>
> Second question - what is about citates - is it include in cost ?
> (It is also not simple question, you can rememeber many opinions which are
> difficult understand without citation of others)
>
> >- Leonid Yegoshin, LY22
>
Received: from cnri by ietf.org id aa28137; 1 Oct 96 15:12 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa00219;
1 Oct 96 15:12 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <SAA16159 at pad-thai.cam.ov.com>; Tue, 1 Oct 1996 18:36:02 GMT
Received: from ingwwdf.sap-ag.de by MIT.EDU with SMTP
id AA11066; Tue, 1 Oct 96 14:35:55 EDT
Received: from sap-ag.de (sapwdf.wdf.sap-ag.de [147.204.3.3]) by ingwwdf.wdf.sap-ag.de (8.6.12/8.6.9) with SMTP id TAA23883 for <cat-ietf at mit.edu>; Tue, 1 Oct 1996 19:35:09 +0100
Received: from p18509.wdf.sap-ag.de by sap-ag.de with SMTP id AA22703
(5.67b8/IDA-1.5 for <cat-ietf at mit.edu>); Tue, 1 Oct 1996 19:35:32 +0100
Received: (from d019080 at localhost) by p18509.wdf.sap-ag.de (8.7.1/8.7.1) id UAA04028; Tue, 1 Oct 1996 20:35:26 +0200
Date: Tue, 1 Oct 1996 20:35:26 +0200
Message-Id: <199610011835.UAA04028 at p18509.wdf.sap-ag.de>
From: "Martin Rex (d019080)" <martin.rex at sap-ag.de>
To: cat-ietf at mit.edu
Cc: Martin.Rex at sap-ag.de
Subject: security context expiration
I'm currently implementing a security context refresh at the
application level and I have found some inconsistencies in the current
documents.
First of all, I'd like to see **context** expiration to be mandatory
in GSS-API v2; i.e. if an application requests a limited lifetime for
a security context, this should be honored. An indefinite lifetime
for security contexts may still be supported, but it should only be
used when (a) the application asks for it or (b) the application asks
for the local default lifetime and the local default lifetime happens
to be indefinite (if a mechanism designer so desires).
As it may be hard to impossible for the GSS-API to synchronize
security context lifetimes between initiator and acceptor, simple
because they have no (legal) means to talk to each other, and since
it may be hard to impossible to expire exactly on the second,
the "mandatory security context expiration" should be reasonable
soft. An uncertainty in the area of 5min plus clock-skew between
initiator and acceptor, and for large time_req maybe 0.1 * time_req
should have be tolerated by the application -- most gssapi mechanism
will do better in reality. It should be at minimum strongly
discouraged to gssapi mechanism implementors to return a security
context with a lifetime of several hours, days, weeks or unlimited
when the application asks for a lifetime of 15 minutes.
Asking for less could create a portability issue, but might still be
reasonable for an application that knows it is dealing with DCE.
Credentials expiration is left up to the implementation
(i.e. when using public key based mechanisms with regular
certificates, the credential lifetime might be a few years).
Specific concerns:
gss_inquire_context() has a return parameter lifetime_rec. The
high-level document doesn't explicitly say that it returns the
lifetime of the context, but that's what name of the function call
intuitively demands. Unfortunately, the C-bindings currently states
that it returns the lifetime of the credentials. (it looks like
an editorial copy&paste error from gss_inquire_cred):
lifetime_rec Integer, modify, optional
The number of seconds for which the credential
will remain valid. If the credential has
expired, this parameter will be set to zero.
If the implementation does not support
credential expiration, the value
GSS_C_INDEFINITE will be returned. Specify
NULL if not required.
gss_init_sec_context(), return parameter time_rec
The description of this parameter in the C-Bindings refers to
credentials expiration being a prerequisite for context expiration.
I think this is inappropriate (btw. this is in RFC1509 as well).
-Martin
Received: from ietf.org by ietf.org id aa06250; 1 Oct 96 18:00 EDT
Received: from cnri by ietf.org id aa05910; 1 Oct 96 17:52 EDT
Received: from aun.uninett.no by CNRI.Reston.VA.US id aa04009;
1 Oct 96 17:52 EDT
Received: from dale.uninett.no (actually trhm7.or.uninett.no) by aun.uninett.no
with SMTP (PP); Tue, 1 Oct 1996 23:51:42 +0200
Received: from dale.uninett.no (localhost [127.0.0.1])
by dale.uninett.no (8.6.9/8.6.12) with ESMTP id WAA02046;
Tue, 1 Oct 1996 22:38:42 +0100
Sender:ietf-request at ietf.org
From: Harald.T.Alvestrand at uninett.no
To: Paul A Vixie <paul at vix.com>
cc: ietf at CNRI.Reston.VA.US
Subject: Re: Anti-Spam BOF Mail List
In-reply-to: Your message of "Mon, 30 Sep 1996 20:04:44 MST." <VIXIE.96Sep30200442 at wisdom.vix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2042.844205920.1 at dale.uninett.no>
Date: Tue, 01 Oct 1996 22:38:41 +0100
Message-ID: <2044.844205921 at dale.uninett.no>
X-Orig-Sender: hta at dale.uninett.no
Source-Info: From (or Sender) name not authenticated.
Paul,
I'll certainly schedule an anti-spam BOF if someone can convince
me that there's a hard technical topic inside of the problem that
it makes sense to address now.
At the moment, I'm not convinced that there's a possible engineering
solution to this social problem that does not involve replacing the
messaging structure of the Internet.
Harald A
Received: from ietf.org by ietf.org id aa08151; 1 Oct 96 18:59 EDT
Received: from cnri by ietf.org id aa08059; 1 Oct 96 18:56 EDT
Received: from ng.netgate.net by CNRI.Reston.VA.US id aa05182;
1 Oct 96 18:56 EDT
Received: from [204.179.131.141] (d47.netgate.net [205.214.160.81]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id QAA10062; Tue, 1 Oct 1996 16:03:27 -0700 (PDT)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v0301045eae775103232f at [204.179.131.141]>
In-Reply-To: <2044.844205921 at dale.uninett.no>
References: Your message of "Mon, 30 Sep 1996 20:04:44 MST."
<VIXIE.96Sep30200442 at wisdom.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Tue, 1 Oct 1996 15:53:23 -0700
To: Harald.T.Alvestrand at uninett.no
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re: Anti-Spam BOF Mail List
Cc: Paul A Vixie <paul at vix.com>, ietf at CNRI.Reston.VA.US
Source-Info: From (or Sender) name not authenticated.
At 2:38 PM -0700 10/1/96, Harald.T.Alvestrand at uninett.no wrote:
>At the moment, I'm not convinced that there's a possible engineering
>solution to this social problem that does not involve replacing the
>messaging structure of the Internet.
I don't know whether the discussion list will prove fruitful, but
I'd guess that reaching community agreement, e.g. about a specific set of
filtering schemes, would make a useful BCP. That is, there is a chance
that some sort of "operations" standard would help. One could also argue
that it would hurt, by making clear to the spammers what hurdle they have
to overcome.
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 by ietf.org id aa10145; 1 Oct 96 21:02 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06928;
1 Oct 96 21:02 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <AAA28698 at pad-thai.cam.ov.com>; Wed, 2 Oct 1996 00:24:19 GMT
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA03825; Tue, 1 Oct 96 20:24:23 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA10305; Tue, 1 Oct 1996 20:24:21 -0400
Date: Tue, 1 Oct 1996 20:24:21 -0400
Message-Id: <9610020024.AA10305 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Martin Rex <martin.rex at sap-ag.de>
Cc: cat-ietf at mit.edu, Martin.Rex at sap-ag.de
In-Reply-To: Martin Rex's message of Tue, 1 Oct 1996 20:35:26 +0200,
BAD MSG:
<199610011835.UAA04028 at p18509.wdf.sap-ag.de>
ubject: Re: security context expiration
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Tue, 1 Oct 1996 20:35:26 +0200
From: "Martin Rex (d019080)" <martin.rex at sap-ag.de>
First of all, I'd like to see **context** expiration to be mandatory
in GSS-API v2; i.e. if an application requests a limited lifetime for
a security context, this should be honored. An indefinite lifetime
for security contexts may still be supported, but it should only be
used when (a) the application asks for it or (b) the application asks
for the local default lifetime and the local default lifetime happens
to be indefinite (if a mechanism designer so desires).
A lot of this boils down to what we really want the context expiration
to be used for. As currently specified by the high-level specification
(the one that mistakenly got approved by the IESG :-), the language
states that the mechanism may return a context lifetime that may be
completely unrelated to the request context lifetime:
The lifetime_req input specifies a desired upper bound for the
lifetime of the context to be established, with a value of 0 used to
request a default lifetime. The lifetime_rec return value indicates
the length of time for which the context will be valid, expressed as
an offset from the present; depending on mechanism capabilities,
credential lifetimes, and local policy, it may not correspond to the
value requested in lifetime_req. If no constraints on context
lifetime are imposed, this may be indicated by returning a reserved
value representing INDEFINITE lifetime_req. The value of lifetime_rec
is undefined unless the routine's major_status indicates
GSS_S_COMPLETE.
There is a hint that the lifetime_rec should be no larger than
lifetime_req ("desired upper bound"), but it's not really clear whether
or not the GSSAPI mechanism is obliged to comply with the desires of the
application programmer. If this is what we want, then we should put
this in the queue of things to be changed when next progress the
high-level spec.
It's also not currently how the Krb5 GSSAPI implementation is
implemented, but it certainly wouldn't be hard to cap the context
lifetime to the requested context lifetime. Context lifetime really
doesn't mean anything to Kerberos anyway, and in the OV implementation
we artifically equate context lifetime with the ticket lifetime. It
wouldn't be hard to change this.
However, looking at RFC 1964, there's nothing which would stop an
implementation from always returning INDEFINITE for the credential and
context lifetime, if it so choose. As far as I can tell this would be a
legal implementation of RFC 1964.
- Ted
Received: from ietf.org by ietf.org id aa23752; 2 Oct 96 8:30 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa23621; 2 Oct 96 8:21 EDT
Received: from [137.155.100.216] by IETF.CNRI.Reston.VA.US id aa00684;
2 Oct 96 8:21 EDT
Received: from morgan.cnu.edu (morgan.cnu.edu [137.155.12.216]) by morgan.cnu.edu (8.7.3/8.6.9) with SMTP id IAA18453; Wed, 2 Oct 1996 08:21:01 -0400 (EDT)
Date: Wed, 2 Oct 1996 08:21:01 -0400 (EDT)
Sender:ietf-request at ietf.org
From: "J. Patrick Narkinsky" <patrick at cnu.edu>
To: Gary Scott Malkin <gmalkin at xylogics.com>
cc: Valdis.Kletnieks at vt.edu, schulzrinne at cs.columbia.edu,
ietf at IETF.CNRI.Reston.VA.US
Subject: Re: one example of e-mail abuse commercialized
In-Reply-To: <4252.9609301804 at huey.xylogics.com>
Message-ID: <Pine.GSO.3.95.961002082041.18401A-100000 at morgan.cnu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 30 Sep 1996, Gary Scott Malkin wrote:
> > Do we *really* want to hand the war on spam to them? First thing you'll
> > know, some senior congressman will find a way to turn it into pork for
> > his home district.
>
> I thought spam was pork ;-)
>
I don't think you want to KNOW what spam really is :)
Patrick
---------------------------------------------------------------------------
J. Patrick Narkinsky |
<patrick at cc.cnu.edu> |Over the router, through the bridge,
Comp. Systems Sr. Engineer |past the T1, bounce off MAE-East,
CNU Computer Center | nothing but net.
(804)594-7180 |
---------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa03886; 2 Oct 96 10:23 EDT
Received: from localhost by ietf.org id aa01584; 2 Oct 96 10:00 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-smirnov-ion-earth-00.txt
Date: Wed, 02 Oct 1996 10:00:50 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610021000.aa01584 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : EARTH - EAsy IP multicast Routing THrough ATM clouds
Author(s) : M. Smirnov
Filename : draft-smirnov-ion-earth-00.txt
Pages : 8
Date : 10/01/1996
The EARTH could be positioned between MARS [1] and VENUS [2]. This document
describes a solution simplifying distribution of IP multicast flows over
ATM clouds with the use of point-to-multipoint connections. The EARTH
solution includes: IP multicast addresses (Class D) resolution to ATM
addresses; support for a multicast group management and receiver-initiated
quality of service (QoS) specification; multiple LISs sharing the same
physical ATM network. Similarly to separation of IP addresses to unicast
and multicast classes, the EARTH proposal separates logical IP subnets as
an option to speed up implementation. EARTH differs from MARS: address
resolution is made only for IP Class D addresses; multiple LISs could be
served by a single EARTH server; EARTH server belongs to a `multicast LIS'.
On contrary to VENUS proposal, EARTH simplifies bypassing Mrouters and
requires no coordination of multiple MARSs. This document, proposing a
solution not yet implemented completely, is intended to help focus ION
efforts.
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-smirnov-ion-earth-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-smirnov-ion-earth-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.a
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-smirnov-ion-earth-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.
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: <19961001163504.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-smirnov-ion-earth-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-smirnov-ion-earth-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961001163504.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03870; 2 Oct 96 10:23 EDT
Received: from localhost by ietf.org id aa01638; 2 Oct 96 10:01 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-souvatzis-ipv6-arcnet-00.txt
Date: Wed, 02 Oct 1996 10:01:14 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610021001.aa01638 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Method for the Transmission of IPv6 Packets over
ARCnet Networks.
Author(s) : I. Souvatzis
Filename : draft-souvatzis-ipv6-arcnet-00.txt
Pages : 4
Date : 10/01/1996
This memo specifies a frame format for transmission of IPv6 [IPV6] packets
and the method of forming IPv6 link-local addresses on ARCnet networks.
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-souvatzis-ipv6-arcnet-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-souvatzis-ipv6-arcnet-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.a
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-souvatzis-ipv6-arcnet-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.
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: <19961001165501.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-souvatzis-ipv6-arcnet-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-souvatzis-ipv6-arcnet-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961001165501.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03885; 2 Oct 96 10:23 EDT
Received: from localhost by ietf.org id aa01602; 2 Oct 96 10:00 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-barber-nntp-news-00.txt
Date: Wed, 02 Oct 1996 10:00:58 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610021000.aa01602 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Network News Transport Protocol
Author(s) : S. Barber
Filename : draft-barber-nntp-news-00.txt
Pages : 31
Date : 10/01/1996
The Network News Transport Protocol has been in use in the Internet for a
decade and remains one of the most popular protocols (by volume) in use
today. This document is a replacement for RFC 977 and officially updates
the protocol specification. It clarifies some vagueness in RFC 977,
includes some new base functionality and provides a specific mechanism to
add standardized extensions to NNTP.
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-barber-nntp-news-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-barber-nntp-news-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.a
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-barber-nntp-news-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.
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: <19961001164027.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-barber-nntp-news-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-barber-nntp-news-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961001164027.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03882; 2 Oct 96 10:23 EDT
Received: from localhost by ietf.org id aa01621; 2 Oct 96 10:01 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-ferguson-ingress-filtering-00.txt
Date: Wed, 02 Oct 1996 10:01:04 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610021001.aa01621 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Network Ingress Filtering
Author(s) : P. Ferguson
Filename : draft-ferguson-ingress-filtering-00.txt
Pages : 6
Date : 10/01/1996
Recent occurrences of various Denial of Service attacks which have employed
forged source addresses have proven to be a troublesome issue for Internet
Service Providers and the Internet community overall. This paper discusses
a simple, effective and straightforward method for using ingress traffic
filtering to deny attacks which use "invalid" source addresses; prefixes
which are not being legitimately advertized to the Internet via a
particular service provider gateway.
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-ferguson-ingress-filtering-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ferguson-ingress-filtering-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.a
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ferguson-ingress-filtering-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.
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: <19961001164609.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ferguson-ingress-filtering-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ferguson-ingress-filtering-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961001164609.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03874; 2 Oct 96 10:23 EDT
Received: from localhost by ietf.org id aa01656; 2 Oct 96 10:01 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
cc: cat-ietf at mit.edu
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-myers-auth-sasl-05.txt
Date: Wed, 02 Oct 1996 10:01:30 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610021001.aa01656 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Simple Authentication and Security Layer
Author(s) : J. Myers
Filename : draft-myers-auth-sasl-05.txt
Pages : 12
Date : 10/01/1996
This document describes a method for adding authentication support to
connection-based protocols. To use this specification, a protocol includes
a command for identifying and authenticating a user to a server and for
optionally negotiating protection of subsequent protocol interactions. If
its use is negotiated, a security layer is inserted between the protocol
and the connection. This document describes how a protocol specifies such
a command, defines several mechanisms for use by the command, and defines
the protocol used for carrying a negotiated security layer over the
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-myers-auth-sasl-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-myers-auth-sasl-05.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.a
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-myers-auth-sasl-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.
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: <19961001171755.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-myers-auth-sasl-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-myers-auth-sasl-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961001171755.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07774; 2 Oct 96 11:07 EDT
Received: from localhost by ietf.org id aa07414; 2 Oct 96 11:04 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-10.txt
Date: Wed, 02 Oct 1996 11:04:07 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610021104.aa07414 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-10.txt
Pages : 48
Date : 10/01/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.
Note that while this protocol was developed for use with
NBMA subnetworks, it is possible, if not likely, that it will be applied to
BMA subnetworks as well. However, this usage of NHRP is for further study.
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 (see [13]).
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-10.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rolc-nhrp-10.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.a
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
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-10.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.
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: <19961001162416.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rolc-nhrp-10.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rolc-nhrp-10.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961001162416.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07773; 2 Oct 96 11:07 EDT
Received: from localhost by ietf.org id aa07398; 2 Oct 96 11: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-kessler-primer-v2-00.txt
Date: Wed, 02 Oct 1996 11:04:01 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610021104.aa07398 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Primer On Internet and TCP/IP Tools and Utilities
Author(s) : G. Kessler, S. Shepard
Filename : draft-kessler-primer-v2-00.txt
Pages : 36
Date : 10/01/1996
This memo is an introductory guide to some of the TCP/IP and Internet tools
and utilities that allow users to access the wide variety of information on
the network, from determining if a particular host is up to viewing a
multimedia thesis on foreign policy. It also describes discussion lists
accessible from the Internet, ways to obtain Internet and TCP/IP documents,
and some resources that help users weave their way through the Internet.
This memo may be used as a tutorial for individual self-learning, a
step-by-step laboratory manual for a course, or as the basis for a site's
users manual. It is intended as a basic guide only and will refer to other
sources for more detailed 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-kessler-primer-v2-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-kessler-primer-v2-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.a
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-kessler-primer-v2-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.
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: <19961001161500.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-kessler-primer-v2-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-kessler-primer-v2-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961001161500.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09110; 2 Oct 96 11:27 EDT
Received: from cnri by ietf.org id aa08897; 2 Oct 96 11:23 EDT
Received: from ginger.lcs.mit.edu by CNRI.Reston.VA.US id aa12357;
2 Oct 96 11:23 EDT
Received: by ginger.lcs.mit.edu
id AA16186; Wed, 2 Oct 96 11:22:40 -0400
Date: Wed, 2 Oct 96 11:22:40 -0400
Sender:ietf-request at ietf.org
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9610021522.AA16186 at ginger.lcs.mit.edu>
To: ietf at CNRI.Reston.VA.US
Subject: Re: one example of e-mail abuse commercialized
Cc: jnc at ginger.lcs.mit.edu
Source-Info: From (or Sender) name not authenticated.
From: "J. Patrick Narkinsky" <patrick at cnu.edu>
this is not a technical problem, it's a social problem. And, speaking as
a computer engineer, I'd rather let the specialists in _SOCIAL_ problems
deal with it (namely the legislators/government)
<This comment has wider applicability than just the spam problem, which is why
I inundate you all with it...>
Unfortunately, I doubt national governments will be much good at attacking
this problem, as they are with most problems on the Internet, because of the
limited scope of their power - on the Internet, Timbuktu is (effectively) just
as close to you as the office down the hall.
(National governments don't yet seem to be ready to face up to the painful
truth that modern technology, and the global economy, are more and more making
every place in the world next door to every other place, and sharply limiting
the *effective* power of national governments in the process. Then again, it's
no surprise that bureaucracies don't like to admit a loss of power....)
So, I doubt national legislation will be much use in curbing spammers - or a
lot of other policy problems that the Internet will face, down the road (such
as the inevitable fights over the inevitable imposing charges for routing
advertisements). I'm not sure what exactly we are going to do about that class
of problem, butit's something we need to start thinking about.
Noel
PS: I'm also dubious that technology will completely solve the problem -
unless you want to pre-clear everyone from whom you've never heard before,
before they can send you mail. Maybe we can make it harder to send out
zillions of individual pieces of mail - but I leave that to the spam list.
Received: from ietf.org by ietf.org id aa09687; 2 Oct 96 11:35 EDT
Received: from localhost by ietf.org id aa07445; 2 Oct 96 11: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-heffernan-tcp-md5-02.txt
Date: Wed, 02 Oct 1996 11:04:09 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610021104.aa07445 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : TCP MD5 Signature Option
Author(s) : A. Heffernan
Filename : draft-heffernan-tcp-md5-02.txt
Pages : 4
Date : 10/01/1996
This memo describes a TCP extension to enhance security for selected TCP
applications. It defines a new TCP option for carrying an MD5 digest in a
TCP segment. This digest acts like a signature for that segment,
incorporating information known only to the connection end points. Using
this option in the way described in this paper significantly reduces the
danger from security attacks on critical TCP applications on the Internet.
This document specifies an experimental protocol for use in 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-heffernan-tcp-md5-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-heffernan-tcp-md5-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.a
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-heffernan-tcp-md5-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.
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: <19961001160727.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-heffernan-tcp-md5-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-heffernan-tcp-md5-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961001160727.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09718; 2 Oct 96 11:35 EDT
Received: from localhost by ietf.org id aa09492; 2 Oct 96 11:32 EDT
To: IETF-Announce: ;
cc: mbeaulie at ietf.org, mburle at aol.com
Subject: IETF MAILING: INTRO: December 9-13, 1996/San Jose, CA
Date: Wed, 02 Oct 1996 11:32:47 -0400
Sender:ietf-announce-request at ietf.org
From: Marcia Beaulieu <mbeaulie at ietf.org>
Message-ID: <9610021132.aa09492 at ietf.org>
Dear IETFers:
Following this message, you will receive three more regarding:
IETF REGISTRATION
AT-A-GLANCE
AGENDA
The following information is/will be available via the Web.
Agenda
At-A-Glance
Registration Form
Miscellaneous:
shipping information
directions
public transportation
WG and BOF Agendas
Tao: Guide for New Attendees
WWW
-----
<http://www.ietf.org> Click on the link for "meetings" and you will
find an entry for the San Jose meeting.
The following information is available via the remote directories:
Agenda
At-A-Glance
Registration Form
Tao: Guide for New Attendees
Travel Directions
FTP
-----
IETF Information is available by anonymous FTP from several sites.
US East Coast Address: ds.internic.net (198.49.45.10)
US West Coast Address: ftp.isi.edu (128.9.0.32)
Europe Address: nic.nordu.net (192.36.148.17)
Pacific Rim Address: munnari.oz.au (128.250.1.21)
cd ietf
ls *0mtg*
NOTE: Though we'd prefer to have payment of the meeting fee as soon
as possible, we definitely want immediate notification that you are
planning on coming. So, even though you know that payment will be
delayed for one reason or another, SEND THE RSVP FORM IN ANYWAY.
Received: from ietf.org by ietf.org id aa10377; 2 Oct 96 11:39 EDT
Received: from localhost by ietf.org id aa09798; 2 Oct 96 11:36 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: ietf-rsvp at ietf.org
cc: mbeaulie at ietf.org, mburle at aol.com
Subject: IETF MAILING: RSVP: December 9-13, 1996/San Jose, CA
Date: Wed, 02 Oct 1996 11:36:51 -0400
X-Orig-Sender: mbeaulie at ietf.org
Message-ID: <9610021136.aa09798 at ietf.org>
REGISTRATION FORM
37th Internet Engineering Task Force - Page 1 of 2
December 9-13, 1996
San Jose, California, USA
Please print or type:
Name (Mr/Dr/Ms)__________________________________________________________
Title____________________________________________________________________
Organization_____________________________________________________________
Address__________________________________________________________________
_________________________________________________________________________
City_____________________________State_____________Postal Code___________
Country__________________________________________________________________
Telephone______________________________Fax_______________________________
Email____________________________________________________________________
Do you plan to attend the Sunday, DECEMBER 8th NEWCOMER'S ORIENTATION at
1530?
YES___ NO___
Do you plan to attend the Sunday, DECEMBER 8th reception at 17:00?
YES___ NO___
The IETF Proceedings are available electronically. Would you still
like a hard copy?
YES___ NO ___
US$250.00 Registration postmarked on or BEFORE, Friday, November 8, 1996.
US$270.00 (US$250.00 + US$20.00 late fee) Registration postmarked after
Friday, November 8, 1996.
Method of payment: ___AMEX ___VISA ___MC ___Diners ___Check
(U.S. dollars, drawn on a U.S. Bank), payable to:
Corporation for National Research Initiatives
Account No.____________________________ Expiration Date__________________
Cardholder Name__________________________________________________________
Cardholder Signature_____________________________________________________
Registration Forms can be sent via electronic mail, facsimile, or postal mail:
Electronic: ietf-rsvp at ietf.org
Facsimile: +1-703-758-5913
Postal: Corporation for National Research Initiatives
Accounting Department - 37th IETF Meeting
1895 Preston White Drive, Suite 100
Reston, VA 20191-5434 USA
REGISTRATION FORM
37th Internet Engineering Task Force - Page 2 of 2
December 9-13, 1996
San Jose, California, USA
IMPORTANT:
1. Payment MAY, but does NOT have to, accompany the Form.
2. As long as your Form is postmarked by the deadline date of
November 8, 1996, you are locked in to pay the lower registration
fee of $250.00 (e.g., send us your form via e-mail by the
deadline date and pay the $250.00 fee later via postal
mail). When paying by company check, be sure that your Accounting
Department knows that you qualified yourself for the lower rate.
3. Payment is accepted on-site.
4. Register ONE person per form. Substitutions are NOT allowed.
5. Include a completed Registration Form with payment.
6. Purchase orders are NOT accepted.
7. DD Form 1556 IS accepted.
8. We CANNOT invoice for payment.
9. Registration Forms will be accepted via electronic mail and
facsimile until 1300ET on Wednesday, December 4, 1996.
10. Requests for refunds must be received by 1700ET, Thursday,
December 5, 1996. No refunds will be processed beyond this
point.
11. REFUND POLICY: Refunds are subject to a US$20.00 service charge.
Late fees WILL NOT be refunded.
12. Your registration fee includes Sunday evening reception (cash bar),
and a daily continental breakfast and coffee breaks.
For additional information or assistance, please contact +1-703-620-8990,
+1-703-758-5913 (Fax) or ietf-rsvp at ietf.org. Direct all inquiries
to: 37th IETF Meeting - San Jose, California, USA
Received: from ietf.org by ietf.org id aa10550; 2 Oct 96 11:40 EDT
Received: from localhost by ietf.org id aa10328; 2 Oct 96 11:38 EDT
To: IETF-Announce: ;
cc: mbeaulie at ietf.org, mburle at aol.com
Subject: IETF MAILING: AT-A-GLANCE: December 9-13, 1996/San Jose, CA
Date: Wed, 02 Oct 1996 11:38:52 -0400
Sender:ietf-announce-request at ietf.org
From: Marcia Beaulieu <mbeaulie at ietf.org>
Message-ID: <9610021138.aa10328 at ietf.org>
37th INTERNET ENGINEERING TASK FORCE Mailing Date: Oct. 2, 1996
AT-A-GLANCE
DATES: December 9-13, 1996
HOTEL/MEETING SITE: San Jose Fairmont Hotel
170 South Market Street
San Jose, CA 95113-2395
Phone: 1 (408) 998-1900 or 1 (800) 527-4727
{fax: 1 (408) 280-6072}
CI 1600; CO 13:00
340 Rooms reserved until Friday, November 8, 1996.
US$122.00/single; US$132.00/double
(please add 10% tax).
Specify: IETF Group
NEWCOMER'S Sunday, December 8, 1996
ORIENTATION: 15:30 - 16:30
PLEASE NOTE THAT THE TIME IS ONE HOUR EARLIER THAN
PREVIOUS MEETINGS
San Jose Fairmont Hotel
Room: Crystal Room
PRE-REGISTRATION: Sunday, December 8, 1996
17:00 - 19:00 (reception)
PLEASE NOTE THAT THE TIME IS ONE HOUR EARLIER THAN
PREVIOUS MEETINGS
San Jose Fairmont Hotel
Room: Regency I & II
REGISTRATION: Monday, December 9, 1996
and BREAKS 08:00 - 18:00
Tuesday, December 10 - Thursday, December 12, 1996
08:30 - 18:00
Friday, December 13, 1996
08:30 - 12:00
San Jose Fairmont Hotel
Room: Market St. Foyer
TERMINAL ROOM: Gold Room
ATTENDANCE FEE: PAYMENT BY: Credit Card or Check
AIRLINE: United Airlines (special rate roundtrip only)
1 (800) 521-4041 Meeting ID: 566RE (IETF)
We regret that discounted fares are not
available for international flights
AIRPORT: San Jose International
PARKING: Current rate as of February 1, 1996 is $9.50 per day.
SHUTTLE: TBD
Received: from ietf.org by ietf.org id aa10734; 2 Oct 96 11:41 EDT
Received: from localhost by ietf.org id aa10400; 2 Oct 96 11:39 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
