[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
Received: from ietf.org by ietf.org id aa02570; 26 Feb 97 2:50 EST
Received: from cnri by ietf.org id aa02262; 26 Feb 97 2:41 EST
Received: from sunhegering7.nm.informatik.uni-muenchen.de by CNRI.Reston.VA.US
id aa03801; 26 Feb 97 2:41 EST
Received: from hpheger9.nm.informatik.uni-muenchen.de (hpheger9.nm.informatik.uni-muenchen.de [129.187.214.29]) by sunhegering7.nm.informatik.uni-muenchen.de (8.7.5/8.6.10) with ESMTP id IAA09983; Wed, 26 Feb 1997 08:34:48 +0100 (MET)
Received: from localhost (neumair at localhost) by hpheger9.nm.informatik.uni-muenchen.de (8.7.5/8.6.10) with SMTP id IAA18455; Wed, 26 Feb 1997 08:34:40 +0100 (MET)
Date: Wed, 26 Feb 1997 08:34:40 +0100 (MET)
Sender:ietf-request at ietf.org
From: Bernhard Neumair <neumair at nm.informatik.uni-muenchen.de>
To: dbworld at cs.wisc.edu, dec_wireless at samson.zko.dec.com, dini at crim.ca,
end2end-interest at venera.isi.edu, enternet at bbn.com,
gcomlist1 at manjaro.ece.iit.edu, giga at tele.pitt.edu, globecom at signet.com.sg,
hipparch at sophia.inria.fr, ieee.announce at bellcore.com,
ieee_rtc_list at cs.tamu.edu, ieeetcpc at ccvm.sunysb.edu,
ietf at CNRI.Reston.VA.US, ifip-6-1 at labs-n.bbn.com, ifip-nm at bbn.com,
isadsoc at fokus.gmd.de, itc at fokus.gmd.de
Subject: CALL FOR PAPERS: JOURNAL OF NETWORK AND SYSTEMS MANAGEMENT
Message-ID: <Pine.HPP.3.95q.970226083410.18342C-100000 at hpheger9.nm.informatik.uni-muenchen.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
****************************************************
*** Please note the new deadline for submissions ***
****************************************************
[Apologies if you receive multiple copies of this.]
------------------------------------------------------------------
*********************
* Deadline Extended *
*********************
CALL FOR PAPERS
JOURNAL OF NETWORK AND SYSTEMS MANAGEMENT
Special Issue on
Managing Mobility and Mobile Computing Systems
Guest Editors:
Bernhard Neumair (University of Munich)
Rene Wies (TTI TECTRAN GmbH)
During the recent years Mobile Computing has become a very
important trend in the usage of computing systems. The advantages
of mobility and the increasing availability of adequate hardware
and software have promoted the development and deployment of
wireless LANs. Furthermore, with greater distances being bridged
by corporate networks, and with world-wide network access, mobile
computing systems can be increasingly used almost anywhere and any
time without a restriction on the available services (e.g., mail,
WWW, etc.).
Managing these mobile systems, the related services, data, and
networks as well as managing the mobility aspects of users (e.g.,
location of home directories, applications, etc.), however, are
still unsolved problems. This special issue is intended to
address these issues and to provide hints for future directions.
The focus of this special issue will be on, but is not limited to,
the following topics:
o Applicability of existing management concepts, tools,
platforms, architectures, etc. to mobile computing
o New concepts, tools, and protocols needed for the
management of mobility and mobile computing systems
o Aspects of dynamic management domains and management
policies incorporating mobile computing systems
o Management requirements imposed by new services and
applications, and new techniques supporting mobility
(e.g., replicating file systems, caching strategies)
o Management requirements imposed by new technologies and
standards (Wireless LANs, HIPERLAN, IEEE P802.11, Mobile
IP, etc.)
o Change and configuration management for mobile
systems (dynamic configuration, downloading and
customizing configurations), and integration aspects
o Security and accounting aspects for mobile systems
o Managing and integrating PDAs
Instructions to Authors:
Please submit four copies of your manuscript, not exceeding 20
double-spaced type-written pages, to one of the Guest Editors
(postscript files by e-mail are also welcome). Please prepare
manuscripts according to the Instructions to Contributors which
can be found in any copy of the Journal. An electronic copy of
this can be obtained by visiting JNSM www page at URL
http://www.cstp.umkc.edu/jnsm/.
Please include the authors' names, addresses, telephone and fax
numbers, and e-mail addresses.
Guest Editors:
Dr. Bernhard Neumair
Department of Computer Science
University of Munich
Oettingenstrasse 67, D-80538 Munich, Germany
Phone: +49-89-2178-2171
Fax: +49-89-2178-2262
E-Mail: neumair at informatik.uni-muenchen.de
Dr. Rene Wies
TTI TECTRAN GmbH
P.O. Box 251
D-82026 Gruenwald/Munich, Germany
Phone: +49-89-641-97040
Fax: +49-89-641-4299
E-Mail: r.wies at ieee.org
Schedule:
Manuscript due: March 30, 1997
Notification of Acceptance: July 30, 1997
Revised Manuscript due: September 30, 1997
Publication Date: First Quarter 1998
Received: from ietf.org by ietf.org id aa05749; 26 Feb 97 4:48 EST
Received: from cnri by ietf.org id aa05641; 26 Feb 97 4:44 EST
Received: from emout14.mx.aol.com by CNRI.Reston.VA.US id aa05651;
26 Feb 97 4:44 EST
Received: (from root at localhost)
by emout14.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0)
id EAA19649;
Wed, 26 Feb 1997 04:41:18 -0500 (EST)
Date: Wed, 26 Feb 1997 04:41:18 -0500 (EST)
Sender:ietf-request at ietf.org
From: GlobalIS at aol.com
Message-ID: <970226044115_-1172476214 at emout14.mail.aol.com>
To: DOSLYNX-DEV at raven.cc.ukans.edu, HPV at sonoma.edu, IETF at CNRI.Reston.VA.US,
POWDERWORKS at cs.colorado.edu
Subject: NEW COMPUTER VIRUS ALERT!!!!
Source-Info: From (or Sender) name not authenticated.
WARNING!!!!!!!
There are several new and highly dangerous internet-spread viruses that could
cause hundreds, even thousands of dollars' worth of damage to your hardware
and/or software. GIS (Global Information Services) has compiled all the
latest data on these newest viruses, as well as the older ones. Learn how to
protect yourself!!!
For more information, reply with the word "information".
Received: from ietf.org by ietf.org id aa11187; 26 Feb 97 8:27 EST
Received: from mersey.hursley.ibm.com by ietf.org id aa11059; 26 Feb 97 8:23 EST
Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03)
id AA64734; Wed, 26 Feb 1997 13:21:19 GMT
Date: Wed, 26 Feb 1997 13:21:19 GMT
Message-Id: <9702261321.AA64734 at hursley.ibm.com>
Sender:ietf-request at ietf.org
From: "(Brian E Carpenter)" <brian at hursley.ibm.com>
Subject: don't shoot the messenger
To: ietf at ietf.org
Reply-To: ietf at ietf.org
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 895
Source-Info: From (or Sender) name not authenticated.
I hesitate to do this but for those of you that don't
receive the ISOC electronic newsletter, the following snip
may be of interest.
"* SPAMMER LAUNCHES ISP FOR OTHER COMMERCIAL E-MAILERS
Cyber Promotions, Inc., best known for having been kicked off of as many
as 20 different Internet Service Providers for sending unsolicited e-
mail, has announced that it will become an Internet Service Provider
itself. CPI plans to charge its customers $50 per month, enabling them
to send unsolicited mass mailings -- referred to as spams -- as long as
they allow users to remove themselves from such lists and comply with
local, state, and federal laws. When asked why the company had not
thought of this solution earlier, CPI president Sanford Wallace said
that his company had been too busy with lawsuits.
(Cowles/SIMBA Media Daily 20 Feb 1997)"
Don't shoot the messenger :-)
Brian Carpenter
Received: from ietf.org by ietf.org id aa11740; 26 Feb 97 8:35 EST
Received: from AIC.NET by ietf.org id aa11555; 26 Feb 97 8:34 EST
Received: by aic.net for ietf at ietf.org at Wed, 26 Feb 1997 16:31:40 +0300 (GMT)
Message-Id: <199702261331.QAA17592 at aic.net>
Subject: Re: don't shoot the messenger
To: ietf at ietf.org
Date: Wed, 26 Feb 1997 16:31:39 +0300 (GMT)
In-Reply-To: <9702261321.AA64734 at hursley.ibm.com> from "ietf-request at ietf.org" at Feb 26, 97 01:21:19 pm
Sender:ietf-request at ietf.org
From: Edgar Danielian <edd at acm.org>
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> "* SPAMMER LAUNCHES ISP FOR OTHER COMMERCIAL E-MAILERS
> Cyber Promotions, Inc., best known for having been kicked off of as many
> as 20 different Internet Service Providers for sending unsolicited e-
> mail, has announced that it will become an Internet Service Provider
> itself. CPI plans to charge its customers $50 per month, enabling them
> to send unsolicited mass mailings -- referred to as spams -- as long as
> they allow users to remove themselves from such lists and comply with
> local, state, and federal laws. When asked why the company had not
> thought of this solution earlier, CPI president Sanford Wallace said
> that his company had been too busy with lawsuits.
> (Cowles/SIMBA Media Daily 20 Feb 1997)"
I'm sure they will be much more busy after becoming ISP...
IMHO,
-edd
Received: from ietf.org by ietf.org id aa12514; 26 Feb 97 8:50 EST
Received: from popper.pbi.net by ietf.org id aa12392; 26 Feb 97 8:48 EST
Received: from hobbes.eng.pbi.net by popper.PBI.net (4.1/PBI-12/1/95)
id AA14244; Wed, 26 Feb 97 05:46:11 PST
Date: Wed, 26 Feb 1997 05:46:11 -0800 (PST)
Sender:ietf-request at ietf.org
From: Christopher Nielsen <cnielsen at pbi.net>
X-Sender: cnielsen at hobbes.eng.pbi.net
To: ietf at ietf.org
Subject: Re: don't shoot the messenger
In-Reply-To: <9702261321.AA64734 at hursley.ibm.com>
Message-Id: <Pine.GSO.3.95.970226053700.8492s-100000 at hobbes.eng.pbi.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Wed, 26 Feb 1997, (Brian E Carpenter) wrote:
> "* SPAMMER LAUNCHES ISP FOR OTHER COMMERCIAL E-MAILERS
> Cyber Promotions, Inc., best known for having been kicked off of as many
> as 20 different Internet Service Providers for sending unsolicited e-
> mail, has announced that it will become an Internet Service Provider
> itself. CPI plans to charge its customers $50 per month, enabling them
> to send unsolicited mass mailings -- referred to as spams -- as long as
> they allow users to remove themselves from such lists and comply with
> local, state, and federal laws. When asked why the company had not
> thought of this solution earlier, CPI president Sanford Wallace said
> that his company had been too busy with lawsuits.
> (Cowles/SIMBA Media Daily 20 Feb 1997)"
Would it be legally feasible to deny peering agreements or upstream
service to someone like this? They have to either get their upstream
service from -someone- or have a peering agreement. I'd be interested to
see who it is or if they can manage to get a peering agreement with
anyone.
On another note, those who attended the most recent NANOG meeting probably
heard Paul Vixie's solution to spammers: blackhole routes.
--
Christopher Nielsen Pacific Bell Internet Services
Senior Systems Administrator and San Francisco, CA
Security Officer
cnielsen at pbi.net #include <stddsclmr.h>
Received: from ietf.org by ietf.org id aa13854; 26 Feb 97 9:08 EST
Received: from cs.columbia.edu by ietf.org id aa13748; 26 Feb 97 9:06 EST
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA15033; Wed, 26 Feb 1997 09:04:02 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id JAA11225; Wed, 26 Feb 1997 09:04:01 -0500 (EST)
X-Orig-Sender: hgs at cs.columbia.edu
Message-ID: <331442D1.10E1 at cs.columbia.edu>
Date: Wed, 26 Feb 1997 09:04:01 -0500
Sender:ietf-request at ietf.org
From: Henning 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: Christopher Nielsen <cnielsen at pbi.net>
CC: ietf at ietf.org
Subject: Re: don't shoot the messenger
References: <Pine.GSO.3.95.970226053700.8492s-100000 at hobbes.eng.pbi.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Christopher Nielsen wrote:
>
> On Wed, 26 Feb 1997, (Brian E Carpenter) wrote:
>
> > "* SPAMMER LAUNCHES ISP FOR OTHER COMMERCIAL E-MAILERS
> > Cyber Promotions, Inc., best known for having been kicked off of as many
> > as 20 different Internet Service Providers for sending unsolicited e-
> > mail, has announced that it will become an Internet Service Provider
> > itself. CPI plans to charge its customers $50 per month, enabling them
> > to send unsolicited mass mailings -- referred to as spams -- as long as
> > they allow users to remove themselves from such lists and comply with
> > local, state, and federal laws. When asked why the company had not
> > thought of this solution earlier, CPI president Sanford Wallace said
> > that his company had been too busy with lawsuits.
> > (Cowles/SIMBA Media Daily 20 Feb 1997)"
>
> Would it be legally feasible to deny peering agreements or upstream
> service to someone like this? They have to either get their upstream
> service from -someone- or have a peering agreement. I'd be interested to
> see who it is or if they can manage to get a peering agreement with
> anyone.
>
> On another note, those who attended the most recent NANOG meeting probably
> heard Paul Vixie's solution to spammers: blackhole routes.
I'd say: get all the spammers to sign up with one spam-only provider,
find out what IP range they got and add a capability to sendmail to
block that range. Unlike, say, netcom, you don't have to worry about
blocking the mail of innocent bystanders.
>
> --
> Christopher Nielsen Pacific Bell Internet Services
> Senior Systems Administrator and San Francisco, CA
> Security Officer
> cnielsen at pbi.net #include <stddsclmr.h>
--
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 aa15002; 26 Feb 97 9:23 EST
Received: from ietf.ietf.org by ietf.org id aa14422; 26 Feb 97 9:19 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: tcplw at bsdi.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-tcplw-high-performance-00.txt
Date: Wed, 26 Feb 1997 09:19:06 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9702260919.aa14422 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 TCP Large Windows Working
Group of the IETF.
Title : TCP Extensions for High Performance
Author(s) : V. Jacobson, R. Braden, D. Borman
Filename : draft-ietf-tcplw-high-performance-00.txt
Pages : 41
Date : 02/25/1997
This memo presents a set of TCP extensions to improve performance over
large bandwidth*delay product paths and to provide reliable operation over
very high-speed paths. It defines new TCP options for scaled windows and
timestamps, which are designed to provide compatible interworking with
TCP's that do not implement the extensions. The timestamps are used for
two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS
(Protect Against Wrapped Sequences). Selective acknowledgments are not
included in this memo.
This memo updates and obsoletes RFC-1323, a Proposed Standard, with
small clarifications and corrections.
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-tcplw-high-performance-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-tcplw-high-performance-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-tcplw-high-performance-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: <19970226091302.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-tcplw-high-performance-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tcplw-high-performance-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970226091302.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa14999; 26 Feb 97 9:23 EST
Received: from ietf.ietf.org by ietf.org id aa14368; 26 Feb 97 9:18 EST
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-pam-html-fine-trans-00.txt
Date: Wed, 26 Feb 1997 09:18:54 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9702260918.aa14368 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Fine-Grained Transclusion in the
Hypertext Markup Language
Author(s) : A. Pam
Filename : draft-pam-html-fine-trans-00.txt
Pages : 3
Date : 02/25/1997
The word "hypertext" was coined by Theodor Holm Nelson in his paper "A File
Structure for the Complex, the Changing and the Indeterminate", presented
at the ACM 20th national conference in 1965. One of the key concepts in
Nelson's vision of hypertext is "transclusion" or virtual inclusion, which
permits composite documents to be constructed by reference to the original
components rather than by copying.
The Hypertext Markup Language (HTML) is a markup language used to create
hypertext documents that are platform independent. HTML currently
permits the transclusion of various content types using tags which
accept a "SRC" attribute, such as the <IMG>, <EMBED> and <APPLET> tags,
but does not provide a mechanism for transcluding textual content.
This document proposes markup for text transclusions in HTML and
explains its usage.
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-pam-html-fine-trans-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-pam-html-fine-trans-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-pam-html-fine-trans-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: <19970225113525.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-pam-html-fine-trans-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-pam-html-fine-trans-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970225113525.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15004; 26 Feb 97 9:24 EST
Received: from ietf.ietf.org by ietf.org id aa14331; 26 Feb 97 9:18 EST
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-isakmp-oakley-03.txt
Date: Wed, 26 Feb 1997 09:18:45 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9702260918.aa14331 at ietf.org>
--NextPart
Note: This revision includes changes as a result of WG Last Call
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 : The resolution of ISAKMP with Oakley
Author(s) : D. Harkins, D. Carrel
Filename : draft-ietf-ipsec-isakmp-oakley-03.txt
Pages : 32
Date : 02/25/1997
[MSST96] (ISAKMP) provides a framework for authentication and key exchange
but does not define them. ISAKMP is designed to be key exchange
independant; that is, it is designed to support many different key
exchanges.
[Orm96] (Oakley) describes a series of key exchanges-- called "modes"-- and
details the services provided by each (e.g. perfect forward secrecy for
keys, identity protection, and authentication).
This document describes a proposal for using the Oakley Key Exchange
Protocol in conjunction with ISAKMP to obtain authenticated keying
material for use with ISAKMP, and for other security associations
such as AH and ESP for the IETF IPsec DOI.
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-isakmp-oakley-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-oakley-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-ipsec-isakmp-oakley-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.
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: <19970225104523.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-isakmp-oakley-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970225104523.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16504; 26 Feb 97 9:40 EST
Received: from ietf.ietf.org by ietf.org id aa14443; 26 Feb 97 9:19 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-dnsrr-00.txt
Date: Wed, 26 Feb 1997 09:19:09 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9702260919.aa14443 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 Roaming Operations Working
Group of the IETF.
Title : The Roaming Relationship (RR) Record in the DNS
Author(s) : B. Aboba
Filename : draft-ietf-roamops-dnsrr-00.txt
Pages : 15
Date : 02/25/1997
This document describes the use of the Roaming Relationship (RR) record in
the DNS for the description of inter-domain business relationships, as
required for enabling of roaming. In the absence of DNS security, RR
records may be used for determining the existence of a business
relationship between the local ISP and the user's home domain, as well as
the location of an appropriate settlement agent. However, since the RR
records are not secured, other methods (such as hierarchical authentication
routing) must be used in order to validate the business relationship path.
When DNS security is implemented, the business relationship path is
authenticated via digital signatures, and as a result, additional services
may be provided, such as non-repudiation of proxied authentications and
signed receipts for accounting record transfers.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-dnsrr-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-dnsrr-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-roamops-dnsrr-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: <19970225140606.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-dnsrr-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-dnsrr-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970225140606.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16865; 26 Feb 97 9:44 EST
Received: from bells.cs.ucl.ac.uk by ietf.org id aa16595; 26 Feb 97 9:42 EST
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.25501-0 at bells.cs.ucl.ac.uk>; Wed, 26 Feb 1997 14:39:47 +0000
To: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
cc: Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
Subject: Re: don't shoot the messenger
In-reply-to: Your message of "Wed, 26 Feb 1997 09:04:01 EST." <331442D1.10E1 at cs.columbia.edu>
Date: Wed, 26 Feb 1997 14:39:45 +0000
Message-ID: <2235.856967985 at cs.ucl.ac.uk>
Sender:ietf-request at ietf.org
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Source-Info: From (or Sender) name not authenticated.
>> On another note, those who attended the most recent NANOG meeting probably
>> heard Paul Vixie's solution to spammers: blackhole routes.
>I'd say: get all the spammers to sign up with one spam-only provider,
>find out what IP range they got and add a capability to sendmail to
>block that range. Unlike, say, netcom, you don't have to worry about
>blocking the mail of innocent bystanders.
why block them?
mark their traffic as low precedence, AND bill them for it
jon
Received: from ietf.org by ietf.org id aa23096; 26 Feb 97 11:18 EST
Received: from core.IConNet.NET by ietf.org id aa22826; 26 Feb 97 11:14 EST
Received: from localhost (brisco at localhost)
by fs.IConNet.NET (8.8.5/8.8.5) with SMTP id LAA18133;
Wed, 26 Feb 1997 11:12:10 -0500 (EST)
Date: Wed, 26 Feb 1997 11:12:10 -0500 (EST)
Sender:ietf-request at ietf.org
From: "T.P.Brisco" <brisco at iconnet.net>
To: Bill Flanigan <flanigab at ncr.disa.mil>
cc: ietf at ietf.org, Roger WOJA Kermode <woja at media.mit.edu>
Subject: Re: 38th IETF Meeting...Hotel Gripe
In-Reply-To: <9701258569.AA856922921 at ncr.disa.mil>
Message-ID: <Pine.GSO.3.92.970226111101.13091B-100000 at fs.IConNet.NET>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Can someone post a handful of nearby hotels? The lady
at registration wasn't much help ....
Tom
On Tue, 25 Feb 1997, Bill Flanigan wrote:
> Hello Roger,
>
> Maybe you're lucky--well, sort of.
>
> After all, this is Memphis TN (not Memphis, Egypt or Mars) where
> the going rates for hotels/motor inns/motels is in the $50-60
> range--AAA, e.g., lists about 25 (with three-diamond ratings) in that
> price range including a number within brisk-walking distance of the
> Peabody.
Received: from ietf.org by ietf.org id aa23640; 26 Feb 97 11:28 EST
Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa23547;
26 Feb 97 11:26 EST
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA16885; Wed, 26 Feb 97 11:23:35 EST
Received: by dcl.MIT.EDU (5.x/4.7) id AA16627; Wed, 26 Feb 1997 11:23:25 -0500
Date: Wed, 26 Feb 1997 11:23:25 -0500
Message-Id: <9702261623.AA16627 at dcl.MIT.EDU>
Sender:ietf-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
Cc: Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
In-Reply-To: Henning Schulzrinne's message of Wed, 26 Feb 1997 09:04:01 -0500,
<331442D1.10E1 at cs.columbia.edu>
Subject: Re: don't shoot the messenger
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Source-Info: From (or Sender) name not authenticated.
Date: Wed, 26 Feb 1997 09:04:01 -0500
From: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
I'd say: get all the spammers to sign up with one spam-only provider,
find out what IP range they got and add a capability to sendmail to
block that range. Unlike, say, netcom, you don't have to worry about
blocking the mail of innocent bystanders.
MIT has already put that feature (an access list for incoming IP
addresses/subnets) in our sendmail hubs.....
- Ted
Received: from ietf.org by ietf.org id aa23855; 26 Feb 97 11:29 EST
Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa23665;
26 Feb 97 11:28 EST
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA17616; Wed, 26 Feb 97 11:26:09 EST
Received: by dcl.MIT.EDU (5.x/4.7) id AA16632; Wed, 26 Feb 1997 11:26:07 -0500
Date: Wed, 26 Feb 1997 11:26:07 -0500
Message-Id: <9702261626.AA16632 at dcl.MIT.EDU>
Sender:ietf-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Bill Flanigan <flanigab at ncr.disa.mil>
Cc: ietf at ietf.org, Roger WOJA Kermode <woja at media.mit.edu>,
flanigab at ncr.disa.mil
In-Reply-To: Bill Flanigan's message of Tue, 25 Feb 97 17:39:20 EST,
<9701258569.AA856922921 at ncr.disa.mil>
Subject: Re: 38th IETF Meeting...Hotel Gripe
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Source-Info: From (or Sender) name not authenticated.
Date: Tue, 25 Feb 97 17:39:20 EST
From: Bill Flanigan <flanigab at ncr.disa.mil>
Naturally, this can't help, but make me a bit curious about who (if
anyone) is seriously negotiating these rates, and what criteria (if
any) are being used?
IETF attendance is now so large that advance-booking guarantees to
completely fill many hotels in an area (even a year in advance) is
virtually riskless. This should put the IETF hotel-booking folks
firmly in the driver's seat as far as getting the lowest possible room
rate in the meeting hotel and others in the area.
Actually, we have a similar problem to USENIX. The number of meeting
and breakout rooms that we need is extremely small compared to the
number of attendees we have (read: number of paying hotel rooms). Thus,
the number of sites where we can meet are quite limited.
This does make me wonder why there were so few rooms reserved at the
IETF block rate, though. Unless the hotel was hoping that enough other
people would pay the full rate after the IETF block was exhausted,
instead of staying at the $50-$60 motel that's 1/4 mile away....
- Ted
Received: from ietf.org by ietf.org id aa24269; 26 Feb 97 11:35 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa24126; 26 Feb 97 11:34 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id LAA32304;
Wed, 26 Feb 1997 11:31:59 -0500
Message-Id: <199702261631.LAA32304 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Neal McBurnett <nealmcb at bell-labs.com>
Cc: ietf at ietf.org, m.t.hamilton at lut.ac.uk, wright at lbl.gov
Subject: Re: ids-dnsnames-02.txt: add list.domain.name for mail lists
In-Reply-To: Your message of "Tue, 25 Feb 1997 16:58:42 PST."
<9702260058.AA13799 at lever.dr.lucent.com>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <9702260058.AA13799 at lever.dr.lucent.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_383835428P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Wed, 26 Feb 1997 11:31:58 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_383835428P
Content-Type: text/plain; charset=us-ascii
On Tue, 25 Feb 1997 16:58:42 PST, Neal McBurnett said:
> The machines are frequently distinct from the "mail" machine
> for a given organization because the operational characteristics
> and requirements can be very different.
>
> I propose the alias "list" for the "mail list" service.
> It is the most common generic name in the lists I subscribe to.
> Are there common alternatives?
Well.. actually, I suspect that in most cases, the machine name is
either listserv.domain.xyz (for people running LSoft's software),
or majordomo.domain.xyz, or listproc.domain.xyz (for those running
the CREN list processor). I can't remember seeing a machine called
list.domain.xyz, and I've been doing Listserv stuff since 1984 or so.
Are you sure that your "the lists I subscribe to" isn't biased in some
way (for instance, many of your lists are hosted in one domain, so
that domain's preferences impact the names you see)?
The command languages for these 3 products are sufficiently different
that bundling them all under the same 'list' is probably a bad idea.
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_383835428P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMxRlfNQBOOoptg9JAQHCUwP/W7VtJ0FGgeZ3P/U0Ei7Dx7/KgWZ0sFb+
1HMGcZa8UASOZJ6o3NegsAoFHkkJi5rqW574UpN9rJS7476s0wSSMeJg5M+MZYb7
z9/XlB5oMb8UIEEyqMkTaOYSJJBP10ztRsRo42SjGQgTXV3NLrPNo3pPoLnntCiE
YM8CSrLt7aA=
=SbSb
-----END PGP MESSAGE-----
--==_Exmh_383835428P--
Received: from ietf.org by ietf.org id aa25391; 26 Feb 97 11:50 EST
Received: from mailgate22-hme0.a001.sprintmail.com by ietf.org id aa25289;
26 Feb 97 11:47 EST
Received: by mailgate22 (SMI-8.6/SMI-SVR4)
id IAA26897; Wed, 26 Feb 1997 08:45:19 -0800
Message-Id: <199702261645.IAA26897 at mailgate22>
Received: from sdn-ts-020mdrelrp13.dialsprint.net(206.133.13.48) by mailfep2-hme1 via smap (KC5.24)
id Q_10.1.1.6/Q_27061_1_3314689a; Wed Feb 26 08:45:14 1997
Sender:ietf-request at ietf.org
From: "Mark A. Mooney" <markmooney at sprintmail.com>
To: ietf at ietf.org
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: Remove
Date: Wed, 26 Feb 1997 11:44:03 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1160
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Remove markmooney at sprintmail.com
unsubscribe markmooney at sprintmail.com
Received: from ietf.org by ietf.org id aa27448; 26 Feb 97 12:21 EST
Received: from buster.lbl.gov by ietf.org id aa27311; 26 Feb 97 12:18 EST
Received: from [128.3.9.20] by cnrmail.lbl.gov
with ESMTP (Apple Internet Mail Server 1.1.1); Wed, 26 Feb 1997 09:15:28 -0800
X-Sender: wright at cnrmail.lbl.gov
Message-Id: <v03101700af3a1ec9797f at [128.3.9.20]>
In-Reply-To: <199702261631.LAA32304 at black-ice.cc.vt.edu>
References: Your message of "Tue, 25 Feb 1997 16:58:42 PST."
<9702260058.AA13799 at lever.dr.lucent.com>
<9702260058.AA13799 at lever.dr.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 26 Feb 1997 09:15:26 -0800
To: Valdis.Kletnieks at vt.edu, Neal McBurnett <nealmcb at bell-labs.com>
Sender:ietf-request at ietf.org
From: Russ Wright <Wright at lbl.gov>
Subject: Re: ids-dnsnames-02.txt: add list.domain.name for mail lists
Cc: ietf at ietf.org, ids at merit.edu
Source-Info: From (or Sender) name not authenticated.
Thanks for the comments. If anyone else has suggestions perhaps we should
discuss on the ids at merit.edu list rather than the general ietf list.
To address this particular comment- I think Valdis is correct about
avoiding one alias. Having said that it was made pretty clear to me that
the IESG folks who reviewed this document don't want a long list of aliases
in the document.
Russ
At 8:31 AM -0800 2/26/97, Valdis.Kletnieks at vt.edu wrote:
>On Tue, 25 Feb 1997 16:58:42 PST, Neal McBurnett said:
>> The machines are frequently distinct from the "mail" machine
>> for a given organization because the operational characteristics
>> and requirements can be very different.
>>
>> I propose the alias "list" for the "mail list" service.
>> It is the most common generic name in the lists I subscribe to.
>> Are there common alternatives?
>
>Well.. actually, I suspect that in most cases, the machine name is
>either listserv.domain.xyz (for people running LSoft's software),
>or majordomo.domain.xyz, or listproc.domain.xyz (for those running
>the CREN list processor). I can't remember seeing a machine called
>list.domain.xyz, and I've been doing Listserv stuff since 1984 or so.
>Are you sure that your "the lists I subscribe to" isn't biased in some
>way (for instance, many of your lists are hosted in one domain, so
>that domain's preferences impact the names you see)?
>
>The command languages for these 3 products are sufficiently different
>that bundling them all under the same 'list' is probably a bad idea.
>
>
>--
> Valdis Kletnieks
> Computer Systems Engineer
> Virginia Tech
Received: from ietf.org by ietf.org id aa28200; 26 Feb 97 12:33 EST
Received: from mail1.microsoft.com by ietf.org id aa28079; 26 Feb 97 12:30 EST
Received: by mail1.microsoft.com with Internet Mail Service (5.0.1457.3)
id <FWP7TAWC>; Wed, 26 Feb 1997 09:27:27 -0800
Message-ID: <503A2A3C2932CF118D8800805FD44E1802BBD755 at RED-68-MSG>
Sender:ietf-request at ietf.org
From: Eric Fleischman <ericfl at microsoft.com>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: RE: don't shoot the messenger
Date: Wed, 26 Feb 1997 09:22:13 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Source-Info: From (or Sender) name not authenticated.
I see that you have now completed your move.
I have signed up for the next IETF. I am looking forward to seeing you.
-----Original Message-----
From: (Brian E Carpenter) [SMTP:brian at hursley.ibm.com]
Sent: Wednesday, February 26, 1997 5:21 AM
To: ietf at ietf.org
Subject: don't shoot the messenger
I hesitate to do this but for those of you that don't
receive the ISOC electronic newsletter, the following
snip
may be of interest.
"* SPAMMER LAUNCHES ISP FOR OTHER COMMERCIAL E-MAILERS
Cyber Promotions, Inc., best known for having been
kicked off of as many
as 20 different Internet Service Providers for sending
unsolicited e-
mail, has announced that it will become an Internet
Service Provider
itself. CPI plans to charge its customers $50 per month,
enabling them
to send unsolicited mass mailings -- referred to as
spams -- as long as
they allow users to remove themselves from such lists
and comply with
local, state, and federal laws. When asked why the
company had not
thought of this solution earlier, CPI president Sanford
Wallace said
that his company had been too busy with lawsuits.
(Cowles/SIMBA Media Daily 20 Feb 1997)"
Don't shoot the messenger :-)
Brian Carpenter
Received: from ietf.org by ietf.org id aa29219; 26 Feb 97 12:48 EST
Received: from hp.rz.uni-potsdam.de by ietf.org id aa29080; 26 Feb 97 12:45 EST
Received: from rz.uni-potsdam.de (persius.rz.uni-potsdam.de) by hp.rz.uni-potsdam.de with ESMTP
(1.37.109.10G/16.2) id AA240398742; Wed, 26 Feb 1997 18:39:02 +0100
Received: from jhartman.rz.uni-potsdam.de by rz.uni-potsdam.de (SMI-8.6/SMI-SVR4)
id SAA17892; Wed, 26 Feb 1997 18:39:50 +0100
Message-Id: <330B51C9.66BD at pobox.com>
Date: Wed, 19 Feb 1997 20:17:29 +0100
Sender:ietf-request at ietf.org
From: Joerg Hartmann <joerg.hartmann at pobox.com>
Reply-To: ecology at pobox.com
Organization: Oekologie & Innovationen
X-Sender: Joerg Hartmann <joerg.hartmann at pobox.com> (Unverified)
X-Mailer: Mozilla 4.0b1 (Win95; I)
Mime-Version: 1.0
To: ietf at ietf.org
Subject: Re: New Ideas for a WWW standard (fwd)
X-Priority: Normal
References: <199702172128.NAA08323 at server.livingston.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
Would you please stop this talk about plattforms, prefered proprietary
scripting/macro languages and so on?!!! This all does _not_ belong to
IETF.
--
Ecology & Innovations, mailto:ecology at pobox.com,
http://pobox.com/~ecology/
Hebbelstrasse 9, D-14469 Potsdam, Germany Phone: +49-(0)331-27092-15
P.O. Box 600844, D-14408 Potsdam Fax/3: +49-(0)331-27092-17
CEO + MD IT/OS Mr. Joerg Hartmann, mailto:joerg.hartmann at pobox.com,
http://pobox.com/~ecology/joerg.hartmann/
Received: from cnri by ietf.org id aa29636; 26 Feb 97 12:52 EST
Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa17517;
26 Feb 97 12:52 EST
Received: (from daemon at localhost) by external.BSDI.COM (8.8.5/8.8.2) id KAA29876 for telnet-ietf-list at bsdi.com; Wed, 26 Feb 1997 10:43:58 -0700 (MST)
Received: from deis38.deis.unibo.it. (deis38.deis.unibo.it [137.204.57.38]) by external.BSDI.COM (8.8.5/8.8.2) with SMTP id KAA29851 for <telnet-ietf at bsdi.com>; Wed, 26 Feb 1997 10:43:32 -0700 (MST)
Received: by deis38.deis.unibo.it. (SMI-8.6/SMI-SVR4)
id SAA06207; Wed, 26 Feb 1997 18:44:53 +0100
Date: Wed, 26 Feb 1997 18:44:53 +0100
From: Sebastien Boving <seb at deis38.deis.unibo.it>
Message-Id: <199702261744.SAA06207 at deis38.deis.unibo.it.>
To: telnet-ietf at bsdi.com
Subject: long suboptions
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: A0qSjvhHqFUikI85BtsM9g==
Hi,
I'm new on this list, and haven't seen any traffic since i'm following it.
I hope i'm not the onlyone out here.
I'm expanding the Oct 23, 1995 telnet source to make it work with
SESAME authentication (encryption will follow). SESAME uses a GSS-API,
for authentication the client sends a firts encrypted token, the server
checks this and sends his own authentication information back.
The problem is, the token leaves (as far as i can see with the debugging
options) the client ok, but the server always refuses the security token,
even if it shouldn't. The problem is that the token delivered to sesame_is()
(called on receipt of a IS) is much smaller than the actually sent token by
the client.
The server also makes this clear by stating:
td: recv suboption (terminated by TERMINAL TYPE 55, not IAC SE!) AUTHENTICATION
IS SESAME CLIENT|MUTUAL AUTH 96 130 (...)
Actually, the clients asks net_write to send a token of about 1500 bytes to
the server. The server receives this, but at about the 510th (512th?) byte
an IAC is inserted (at what point?), so it thinks the suboption is badly
terminated!
Still this IAC doesn't appear in str_data when the client is sending it!
What is going wrong? Why is this byte inserted in the stream?
TIA, and sorry if this is a stupid question...
Sebastien Boving.
(just another student)
Received: from ietf.org by ietf.org id aa00473; 26 Feb 97 13:08 EST
Received: from iggy.iwsc.com by ietf.org id aa00335; 26 Feb 97 13:06 EST
Received: from bmeandzija_nt (analog_dell.gi.com [168.84.65.19])
by iggy.iwsc.com (post.office MTA v1.9.3 ID# 10-12202) with SMTP
id AAA214; Wed, 26 Feb 1997 10:08:50 -0800
Message-ID: <3314797F.36C at metacomm.com>
Date: Wed, 26 Feb 1997 09:57:19 -0800
Sender:ietf-request at ietf.org
From: Branislav Meandzija <bran at metacomm.com>
Reply-To: bran at metacomm.com
Organization: Meta Communications, Inc.
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: "Theodore Y. Ts'o" <tytso at mit.edu>
CC: Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
Subject: Re: don't shoot the messenger
References: <9702261623.AA16627 at dcl.MIT.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Theodore Y. Ts'o wrote:
>
> Date: Wed, 26 Feb 1997 09:04:01 -0500
> From: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
>
> I'd say: get all the spammers to sign up with one spam-only provider,
> find out what IP range they got and add a capability to sendmail to
> block that range. Unlike, say, netcom, you don't have to worry about
> blocking the mail of innocent bystanders.
>
> MIT has already put that feature (an access list for incoming IP
> addresses/subnets) in our sendmail hubs.....
>
> - Ted
To me this looks too much like censorship. I'll rather be my own
censor.
Branislav
Received: from ietf.org by ietf.org id aa01737; 26 Feb 97 13:26 EST
Received: from aleve.media.mit.edu by ietf.org id aa01438; 26 Feb 97 13:24 EST
Received: from ml.media.mit.edu (ml.media.mit.edu [18.85.13.107]) by media.mit.edu (8.7.5/ML961206) with SMTP id NAA31223 for <ietf at ietf.org>; Wed, 26 Feb 1997 13:21:42 -0500 (EST)
Received: from bad-taste.media.mit.edu by ml.media.mit.edu; (5.65v3.2/1.1.8.2/12Apr96-0443PM)
id AA08312; Wed, 26 Feb 1997 13:21:42 -0500
Date: Wed, 26 Feb 1997 13:21:37 -0500 (EST)
Sender:ietf-request at ietf.org
From: Roger WOJA Kermode <woja at media.mit.edu>
To: ietf at ietf.org
Subject: Re: 38th IETF Meeting...Hotel Gripe
Message-Id: <Pine.OSF.3.91.970226132106.27595D-100000 at bad-taste.media.mit.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
try these on your web browser......
ftp://ftp.ietf.org/ietf/0mtg-at-a-glance-97apr.txt
http://www.fodors.com/ir.cgi?dest=Memphis at 35&2=name
you can find out where the hotels are relative to the meeting site
using....
http://www.city.net/countries/united_states/tennessee/memphis/maps/
woja
Roger Kermode Research Assistant
woja at media.mit.edu tel : +1 617 253 0341
Entertainment & Information Systems Group fax : +1 617 258 6264
MIT Media Lab, 20 Ames St, RmE15-354, Cambridge, MA 02139 USA
On Wed, 26 Feb 1997, T.P.Brisco wrote:
>
>
> Can someone post a handful of nearby hotels? The lady
> at registration wasn't much help ....
>
> Tom
>
> On Tue, 25 Feb 1997, Bill Flanigan wrote:
> > Hello Roger,
> >
> > Maybe you're lucky--well, sort of.
> >
> > After all, this is Memphis TN (not Memphis, Egypt or Mars) where
> > the going rates for hotels/motor inns/motels is in the $50-60
> > range--AAA, e.g., lists about 25 (with three-diamond ratings) in that
> > price range including a number within brisk-walking distance of the
> > Peabody.
>
>
>
Received: from cnri by ietf.org id aa02882; 26 Feb 97 13:46 EST
Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa19180;
26 Feb 97 13:46 EST
Received: (from daemon at localhost) by external.BSDI.COM (8.8.5/8.8.2) id LAA03771 for telnet-ietf-list at bsdi.com; Wed, 26 Feb 1997 11:41:21 -0700 (MST)
Received: from forge.BSDI.COM (dab at forge.BSDI.COM [205.230.224.24]) by external.BSDI.COM (8.8.5/8.8.2) with ESMTP id LAA03755; Wed, 26 Feb 1997 11:40:44 -0700 (MST)
Received: (from dab at localhost) by forge.BSDI.COM (8.8.2/8.7.3) id LAA05265; Wed, 26 Feb 1997 11:40:43 -0700 (MST)
Date: Wed, 26 Feb 1997 11:40:43 -0700 (MST)
From: David Borman <dab at bsdi.com>
Message-Id: <199702261840.LAA05265 at forge.BSDI.COM>
To: seb at deis38.deis.unibo.it, telnet-ietf at bsdi.com
Subject: Re: long suboptions
Sebastien,
> The problem is, the token leaves (as far as i can see with the debugging
> options) the client ok, but the server always refuses the security token,
> even if it shouldn't. The problem is that the token delivered to sesame_is()
> (called on receipt of a IS) is much smaller than the actually sent token by
> the client.
>
> The server also makes this clear by stating:
> td: recv suboption (terminated by TERMINAL TYPE 55, not IAC SE!) AUTHENTICATION
> IS SESAME CLIENT|MUTUAL AUTH 96 130 (...)
>
> Actually, the clients asks net_write to send a token of about 1500 bytes to
> the server. The server receives this, but at about the 510th (512th?) byte
> an IAC is inserted (at what point?), so it thinks the suboption is badly
> terminated!
> Still this IAC doesn't appear in str_data when the client is sending it!
The telnet server accumulates the suboption into a static circular buffer,
which is 512 bytes long. You say you are sending a token of 1500 bytes, so
it is going to wrap that buffer almost 3 times... In telnetd/state.c:
unsigned char subbuffer[512], *subpointer= subbuffer, *subend= subbuffer;
For the quick fix, make the buffer bigger.
-David Borman, dab at bsdi.com
Received: from ietf.org by ietf.org id aa04661; 26 Feb 97 14:07 EST
Received: from cnri by ietf.org id aa04582; 26 Feb 97 14:06 EST
Received: from po2.glue.umd.edu by CNRI.Reston.VA.US id aa19687;
26 Feb 97 14:06 EST
Received: from z.glue.umd.edu (tle at z.glue.umd.edu [128.8.10.71])
by po2.glue.umd.edu (8.8.5/8.8.5) with ESMTP id NAA02927;
Wed, 26 Feb 1997 13:55:53 -0500 (EST)
Received: from localhost (tle at localhost) by z.glue.umd.edu (8.8.5/8.7.3) with SMTP id NAA17128; Wed, 26 Feb 1997 13:55:44 -0500 (EST)
X-Authentication-Warning: z.glue.umd.edu: tle owned process doing -bs
Date: Wed, 26 Feb 1997 13:55:43 -0500 (EST)
Sender:ietf-request at ietf.org
From: Thao Le <tle at eng.umd.edu>
X-Sender: tle at z.glue.umd.edu
To: tccc at ieee.org
cc: vacets-tech at vacets.org
Subject: Call for Papers - Deadline for Submitting Abstracts/Summaries
Message-ID: <Pine.SOL.3.95.970226134556.16556A-100000 at z.glue.umd.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Dear friends
The deadline for submitting abstracts/summaries for VTIC '97 will be the
end of this week (March 31, 1997). We would like to invite you to
submit your own summaries and urge your colleagues to do so.
We look forward to hearing from you and meeting you at VTIC '97.
Best regards,
Thao Le
-----------------------------
Vietnamese Association for
Computing, Engineering Technology and Science (VACETS)
http://www.saigon.com/~vacets
vacets-adcom at vacets.org
CALL FOR PAPERS
1997 VACETS Technical International Conference (VTIC-97)
vtic-tech at vacets.org
San Jose State University, San Jose, California
July 17 - 19, 1997
The second VACETS Technical International Conference will be held
on July 17 and 19, 1997 at San Jose State University, San Jose,
California. The theme of this year conference is "Key Technologies
for the Year 2000". We will focus on advances in 1997 pacing
technologies that we believe will become key technologies in the year
2000.
Instructions to Authors:
Prospective authors are invited to submit research and overview papers
in all engineering and computer, physical, medical and social sciences
disciplines for presentation and/or posting during the conference.
Original papers are solicited in, but are not limited to, the following
areas:
===========================================
(1) Biomedical and Bio-Chemistry Technology
(2) Robotics and Controls Technology
(3) Telecommunications Technology
(4) Computer Systems and Applications
(5) IC Design Technology
(6) Biometric Systems
(7) Energy and Environmental Technology
(8) Speech, Signal, Video, Image Processing Applications
(9) Material and Manufacturing Technologies
(10) Other Sciences, Engineering and Technologies
============================================
Students are encouraged to submit their papers. Accepted papers will
be printed in the conference proceedings under Student Paper Session.
There will be three student paper awards to be presented at the
conference.
Since the format of the conference allows a number of special topics
sessions or workshops to be held, proposals from participants willing
to organize special sessions on relevant topics are also welcomed. The
organizers will be responsible for inviting speakers to their special
sessions.
Schedule
- Submission of proposal for special sessions must be received by
December 15, 1996.
- Submission of one page summary must be received by March 1, 1997.
- Notification of acceptance by April 1, 1997.
- Final manuscripts (photoready papers) are due on May 15, 1997.
Summary Submission
Submission of one page text summary by e-mail to
vtic-tech at vacets.org
is requested. Small black and white illustrations, in pcx format (MS
Windows Paintbrush readable) can also be included in the file, provided
it has been pkzipped and uuencoded. An alternative is to send two
copies of the summary, with illustrations (but not the original
illustrations themselves) to the Technical Program Chair:
Dr. Tran Thong
Micro Systems Engineering, Inc.
6024 SW Jean Rd
Lake Oswego, OR 97035
Fax: 503 635-9610
1. The official language of the conference is English (both paper
and presentation). Vietnamese language submission is encouraged but an
English summary must be included.
2. Please indicate your preferences: oral or poster presentation.
3. The summary should include the name, address (both e-mail and postal)
and phone/fax number of the author(s).
4. Also, to simplify the review process, please indicate the primary
technical area covered by the paper, PLEASE INCLUDE THIS INFORMATION IN
THE SUBJECT LINE OF YOUR E-MAIL, for example: "VTIC-97 paper in
Robotics"
All questions regarding the format of the paper or the acceptance
status should be directed to the Technical Program Chair.
Dr. Tran Thong
Fax: 503 635-9610
E-Mail: trant at teleport.com
Technical Paper Format
Papers submitted will be reviewed by the Conference Proceedings
editorial staff for publication suitability. Editorial changes may be
made to meet technical proceedings publication standards.
1. Paper should be printed on both sides of 8.5 X 11 in (21.6 X 27.9 cm)
white sheets.
2. Begin with the title of the paper, name(s) of author(s), e-mail
address (if available), complete return address, telephone and fax
number.
3. A 10 to 15 lines abstract in "italic"
4. Use Word Processor: Microsoft Word 6.0 (or earlier readable version
or Word Perfect). Font: Arial 10. An alternative is to submit an Adobe
Acrobat pdf file.
5. Leave 1 in (2..54 cm) margin for each side, top and bottom of the
page.
6. Make one or two-column per page.
7. The paper length is limited to 8 pages. Indicate page number in blue
pencil.
8. Submit a 3.5" diskette in MS Word format for text, graphs, tables,
formulas, etc., and two hardcopies of the papers.
9. Mail the paper and diskette to the Technical Program Vice-Chair:
Dr. Thuy Trong Le
Supercomputer Group
Fujitsu America, Inc.
3055 Orchard Drive
San Jose, CA 95134-2022 USA
email: thuy at fujitsu.com
Received: from cnri by ietf.org id aa04696; 26 Feb 97 14:07 EST
Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa19732;
26 Feb 97 14:07 EST
Received: (from daemon at localhost) by external.BSDI.COM (8.8.5/8.8.2) id MAA05271 for telnet-ietf-list at bsdi.com; Wed, 26 Feb 1997 12:02:36 -0700 (MST)
Received: from deis38.deis.unibo.it. (deis38.deis.unibo.it [137.204.57.38]) by external.BSDI.COM (8.8.5/8.8.2) with SMTP id MAA05267; Wed, 26 Feb 1997 12:02:32 -0700 (MST)
Received: by deis38.deis.unibo.it. (SMI-8.6/SMI-SVR4)
id UAA06368; Wed, 26 Feb 1997 20:05:16 +0100
Date: Wed, 26 Feb 1997 20:05:16 +0100
From: Sebastien Boving <seb at deis38.deis.unibo.it>
Message-Id: <199702261905.UAA06368 at deis38.deis.unibo.it.>
To: dab at bsdi.com, telnet-ietf at bsdi.com
Subject: Re: long suboptions
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: 95ebp5TFIaWEIHBEP8IzsA==
> The telnet server accumulates the suboption into a static circular buffer,
> which is 512 bytes long. You say you are sending a token of 1500 bytes, so
> it is going to wrap that buffer almost 3 times... In telnetd/state.c:
>
> unsigned char subbuffer[512], *subpointer= subbuffer, *subend= subbuffer;
>
> For the quick fix, make the buffer bigger.
>
> -David Borman, dab at bsdi.com
>
That was the problem, it now works!
Thanks,
Sebastien.
Received: from ietf.org by ietf.org id aa06465; 26 Feb 97 14:33 EST
Received: from ietf.ietf.org by ietf.org id aa06055; 26 Feb 97 14:27 EST
To: IETF-Announce: ;
Subject: WG ACTION: The Internet and the millenium problem (2000)
Date: Wed, 26 Feb 1997 14:27:50 -0500
Sender:ietf-announce-request at ietf.org
From: Cynthia Clark <cclark at ietf.org>
Message-ID: <9702261427.aa06055 at ietf.org>
A new working group has been formed in the Operational Requirements Area
of the IETF. For additional information, contact the Area Directors
or the WG Chair.
The Internet and the millenium problem (2000)
---------------------------------------------
Chair(s):
Erik Huizer <Erik.Huizer at sec.nl>
Operational Requirements Area Director(s):
Scott Bradner <sob at harvard.edu>
Michael O'Dell <mo at uu.net>
Deirdre Kostick <kostick at qsun.att.com>
Area Advisor
Scott Bradner <sob at harvard.edu>
Mailing lists:
General Discussion:2000 at nic.surfnet.nl
To Subscribe: listserv at nic.surfnet.nl
In Body: subscribe 2000 <your name> in body
Archive:
Description of Working Group:
The Millenium problem
According to the trade press billions of dollars will be spend the
upcoming three years on the year 2000 problem, also called the
millenium problem (though the third millenium will only start in 2001).
This problem consists of the fact that many software packages and some
protocols use a two digit field for the year in a date field. Most of
the problems seem to be in administrative and financial programs, some
of which have been written in archaic languages like Cobol. A lot of
organizations are now starting to make an inventory of which software
and tools they use will suffer from the millenium problem.
....and the Internet
With the increasing popularity of the Internet,
more and more organizations start to use the Internet as a serious
business tool. This means that most organizations will want to analyse
the millenium problems due to the use of Internet protocols and popular
Internet software. In the trade press the first articles suggest that
the Internet will collapse at midnight the 31st of december 1999.
To counter these suggestions (that are obviously wrong) and to avoid
that all over the Internet people will redo the same inventory over and
over again the WG is to make an inventory of all important Internet
protocols and their most popular implementations with respect to the
millenium problem. Only software and protocols directly related to the
Internet will be considered.
The inventory will be published as an informational RFC. The RFC will
contain:
o Description of the year 2000 problems and when they will occur
o Summary of possible solutions and timelines for those solutions
o Inventory of the year 2000 problem in the most popular Internet
protocols and their most popular implementations
o Suggested solutions to the problems noted in the inventory
o A disclaimer that the RFC does not pretend to be complete and that
the proposed solutions should be tested before being relied upon (this
for the US readers).
The WG will only meet once (in Memphis, April 1997), most of the work
will be done via the mailinglist.
Goals and Milestones:
Feb 97 Begin collecting inventory.
Sep 97 Submit Internet-Draft to IESG for publication as an
Informational RFC.
Received: from ietf.org by ietf.org id aa06462; 26 Feb 97 14:33 EST
Received: from ietf.ietf.org by ietf.org id aa06045; 26 Feb 97 14:27 EST
To: IETF-Announce: ;
Subject: WG ACTION: Secure Shell (secsh)
Date: Wed, 26 Feb 1997 14:27:48 -0500
Sender:ietf-announce-request at ietf.org
From: Cynthia Clark <cclark at ietf.org>
Message-ID: <9702261427.aa06045 at ietf.org>
A new working group has been formed in the Security Area
of the IETF. For additional information, contact the Area Directors
or the WG Chair.
Secure Shell (secsh)
--------------------
Chair(s):
Perry Metzger <perry at piermont.com>
Security Area Director(s):
Jeffrey Schiller <jis at mit.edu>
Mailing lists:
General Discussion:ietf-ssh at clinet.fi
To Subscribe: majordomo at clinet.fi
In Body: subscribe ietf-ssh at clinet.fi in body
Archive:
Description of Working Group:
The goal of the working group is to update and standardize the popular
SSH protocol. SSH provides support for secure remote login, secure file
transfer, and secure TCP/IP and X11 forwardings. It can automatically
encrypt, authenticate, and compress transmitted data. The working
group will attempt to assure that the SSH protocol
o provides strong security against cryptanalysis and protocol attacks,
o can work reasonably well without a global key management or
certificate infrastructure,
o can utilize existing certificate infrastructures (e.g., DNSSEC,
SPKI, X.509) when available,
o can be made easy to deploy and take into use,
o requires minimum or no manual interaction from users,
o is reasonably clean and simple to implement.
The resulting protocol will operate over TCP/IP or other reliable but
insecure transport. It is intended to be implemented at the application
level.
Goals and Milestones:
Feb 97 Submit Internet-Draft on SSH-2.0 protocol
Apr 97 Decide on Transport Layer protocol at Memphis IETF.
Aug 97 Finalize upper level protocols at Munich IETF.
Sep 97 Submit Internet-Drafts to IESG to consider for publication as
RFCs.
Dec 97 Meet at DC IETF meeting.
Received: from ietf.org by ietf.org id aa08275; 26 Feb 97 15:06 EST
Received: from box.nl by ietf.org id aa08191; 26 Feb 97 15:04 EST
Received: from cs-gj3-a7.hro.nl (cs-gj3-a7.hro.nl [145.24.129.139]) by box.nl (8.7.5/8.6.9) with SMTP id VAA15386; Wed, 26 Feb 1997 21:01:28 +0100
Date: Wed, 26 Feb 1997 21:01:28 +0100
Message-Id: <199702262001.VAA15386 at box.nl>
X-Sender: unit at box.nl
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ecology at pobox.com
Sender:ietf-request at ietf.org
From: michael_roetto <mike at box.nl>
Subject: Re: New Ideas for a WWW standard (fwd)
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 20:17 19-02-97 +0100, you wrote:
>Would you please stop this talk about plattforms, prefered proprietary
>scripting/macro languages and so on?!!! This all does _not_ belong to
>IETF.
>
I realize that the topic does not per se belong to the IETF list. But if
you had read the document referenced you would have discovered the reasons I
posted to the IETF. Further, judging from the discussion that ensued, it
seems that the topic struck the interest of many who subsribe to the list.
Please see the original document as well as the comments at:
http://www.box.nl/~unit/mike/prop.htm
-michael_roetto
>
>
::::::::::::::::::::::::::::::::::::
Internet Design Unit
http://www.box.nl/~unit/idu
Personal Page:
http://www.box.nl/~unit/mike
::::::::::::::::::::::::::::::::::::
Received: from ietf.org by ietf.org id aa13226; 26 Feb 97 16:04 EST
Received: from ietf.ietf.org by ietf.org id aa12642; 26 Feb 97 15:59 EST
To: IETF-Announce: ;
cc: cat-ietf at mit.edu
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: FTP Security Extensions to Proposed Standard
Reply-to: iesg at ietf.org
Date: Wed, 26 Feb 1997 15:59:25 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9702261559.aa12642 at ietf.org>
The IESG has received a request from the Common Authentication Technology
Working Group to consider "FTP Security Extensions"
<draft-ietf-cat-ftpsec-09.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 March 12, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa14782; 26 Feb 97 16:24 EST
Received: from ietf.ietf.org by ietf.org id aa14605; 26 Feb 97 16:20 EST
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: IMAP4 Referrals to Proposed Standard
Reply-to: iesg at ietf.org
Date: Wed, 26 Feb 1997 16:20:43 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9702261620.aa14605 at ietf.org>
The IESG has received a request to consider IMAP4 Referrals
<draft-gahrns-imap-referrals-01.txt> as a Proposed Standard. This has
been reviewed in the IETF but is not the product of an IETF Working
Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by March 26, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from cnri by ietf.org id aa20552; 26 Feb 97 17:47 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa27668;
26 Feb 97 17:47 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA21493 at pad-thai.cam.ov.com>; Wed, 26 Feb 1997 20:57:51 GMT
Message-Id: <199702262057.PAA17090 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Memphis agenda and discussion solicitation
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 26 Feb 1997 15:57:45 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
CAT-WG members:
The level of discussion on the list has been relatively quiet lately,
and we have one meeting slot assigned for the Memphis IETF. I'd like
to invite all members to initiate and pursue discussions of WG-related
topics, and would like at this time to solicit requests for agenda
time in order that the slot may be used most effectively towards closure
and advancement of active and pending documents.
Thanks, regards, ...
--jl
Received: from cnri by ietf.org id aa06457; 27 Feb 97 2:37 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa03844;
27 Feb 97 2:37 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <GAA10832 at pad-thai.cam.ov.com>; Thu, 27 Feb 1997 06:00:50 GMT
Message-Id: <199702270600.BAB20132 at ig.cs.utk.edu>
To: ftp-wg at hops.ag.utk.edu
Cc: cat-ietf at mit.edu
Subject: [fwd] Last Call: FTP Security Extensions to Proposed Standard
Date: Thu, 27 Feb 1997 01:00:38 -0500
From: Keith Moore <moore at cs.utk.edu>
Precedence: bulk
FTP extensions WG people:
The CAT WG has developed a proposal for security extensions for
FTP, and asked IESG that it be considered for Proposed Standard.
In accordance with the FTPEXT WG charter, which directs it to
review and make recommendations on proposed security extensions
to FTP, I hereby request that the FTPEXT review this document
and make appropriate recommendations. Individuals may of course
submit their own comments independent of the working group.
Note: while the FTPEXT group may of course discuss this proposal on
its mailing list, any recommendations (from either the working group or
individuals) on this proposal should be sent to ietf at ietf.org or
iesg at ietf.org before March 12.
Keith Moore
co-Director, Applications Area
IESG
------- Forwarded Message
To: IETF-Announce:;
cc: cat-ietf at mit.edu
Sender: ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: FTP Security Extensions to Proposed Standard
Reply-to: iesg at ietf.org
Date: Wed, 26 Feb 1997 15:59:25 -0500
Message-ID: <9702261559.aa12642 at ietf.org>
The IESG has received a request from the Common Authentication Technology
Working Group to consider "FTP Security Extensions"
<draft-ietf-cat-ftpsec-09.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 March 12, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
------- End of Forwarded Message
Received: from ietf.org by ietf.org id aa09157; 27 Feb 97 5:36 EST
Received: from ibmmail.com by ietf.org id aa08867; 27 Feb 97 5:26 EST
Received: from uk.ibm.com by ibmmail.COM (IBM VM SMTP V2R3) with BSMTP id 3826;
Thu, 27 Feb 97 05:23:56 EST
Date: Thu, 27 Feb 1997 05:23:58 EST
Sender:ietf-request at ietf.org
From: pfh at uk.ibm.com
To: cat-ietf at mit.edu, ftp-wg at hops.ag.utk.edu, ietf at ietf.org
X-Sender-Info: Paul Ford-Hutchinson
Classification: -- NONE --
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: draft-ietf-cat-ftpsec-09.txt
Message-ID: <9702270526.aa08867 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
Two comments
- The length of time that PROT is valid for is not specified - is it
per data connection; is it cleared with a new AUTH/USER/ ... ...
(I guess the latter, but I don't think it can be an implementation
decision)
- Can PBSZ 0 please define a 'streaming' encryption mechanism (like
TLS (SSL)). This allows us to use this draft to negotiate TLS (with
AUTH and PROT) but then all the stuff about encapsulating the data
channel isn't relevant, as that is done for you by TLS.
So, if 'PBSZ 0' meant
- O.K. then you can send a PROT, and the data stream will be
encrypted for you (the ftp application) lower down, so
it will appear to you as a 'normal' unencapsulated data
connection.
Cheers,
Paul
-.--.---.----.-----.----.---.--.--.---.----.-----.----.---.--.-
Paul Ford-Hutchinson FORDHUP @ NHBVM9 (GBIBMLLL @ IBMMAIL)
IGN EDI Products Development and Support. (pfh at uk.ibm.com)
Warwick (OSU-1) +44 (0)1926 464836 : tie (7)66 4836
Received: from cnri by ietf.org id aa10884; 27 Feb 97 6:48 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa07725;
27 Feb 97 6:48 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <KAA16401 at pad-thai.cam.ov.com>; Thu, 27 Feb 1997 10:24:54 GMT
Message-Id: <9702271024.AA08280 at MIT.EDU>
Date: Thu, 27 Feb 1997 05:24:44 EST
From: pfh at uk.ibm.com
To: cat-ietf at mit.edu, ftp-wg at hops.ag.utk.edu, ietf at ietf.org
X-Sender-Info: Paul Ford-Hutchinson
Classification: -- NONE --
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: draft-ietf-cat-ftpsec-09.txt
Precedence: bulk
Two comments
- The length of time that PROT is valid for is not specified - is it
per data connection; is it cleared with a new AUTH/USER/ ... ...
(I guess the latter, but I don't think it can be an implementation
decision)
- Can PBSZ 0 please define a 'streaming' encryption mechanism (like
TLS (SSL)). This allows us to use this draft to negotiate TLS (with
AUTH and PROT) but then all the stuff about encapsulating the data
channel isn't relevant, as that is done for you by TLS.
So, if 'PBSZ 0' meant
- O.K. then you can send a PROT, and the data stream will be
encrypted for you (the ftp application) lower down, so
it will appear to you as a 'normal' unencapsulated data
connection.
Cheers,
Paul
-.--.---.----.-----.----.---.--.--.---.----.-----.----.---.--.-
Paul Ford-Hutchinson FORDHUP @ NHBVM9 (GBIBMLLL @ IBMMAIL)
IGN EDI Products Development and Support. (pfh at uk.ibm.com)
Warwick (OSU-1) +44 (0)1926 464836 : tie (7)66 4836
Received: from ietf.org by ietf.org id aa13732; 27 Feb 97 9:06 EST
Received: from unlinfo.unl.edu by ietf.org id aa13568; 27 Feb 97 9:02 EST
Received: from unlinfo2.unl.edu by unlinfo.unl.edu (4.1/SMI-4.1)
id AA02935; Thu, 27 Feb 97 07:59:42 CST
Received: by unlinfo2.unl.edu (4.1/SMI-4.1)
id AA00614; Thu, 27 Feb 97 07:59:38 CST
Date: Thu, 27 Feb 1997 07:59:37 -0600 (CST)
Sender:ietf-request at ietf.org
From: thomas keller <tkeller at unlinfo2.unl.edu>
Subject: Re: don't shoot the messenger
To: Branislav Meandzija <bran at metacomm.com>
Cc: "Theodore Y. Ts'o" <tytso at mit.edu>,
Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
In-Reply-To: <3314797F.36C at metacomm.com>
Message-Id: <Pine.3.89.9702270719.A354-0100000 at unlinfo2.unl.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Wed, 26 Feb 1997, Branislav Meandzija wrote:
> Theodore Y. Ts'o wrote:
> > Date: Wed, 26 Feb 1997 09:04:01 -0500
> > From: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
> > I'd say: get all the spammers to sign up with one spam-only provider,
> > find out what IP range they got and add a capability to sendmail to
> > block that range. Unlike, say, netcom, you don't have to worry about
> > blocking the mail of innocent bystanders.
>>> MIT has already put that feature (an access list for incoming IP
>>> addresses/subnets) in our sendmail hubs.....
>>>> To me this looks too much like censorship. I'll rather be my own
>>>> censor.
Censorship? Hardly. Spamming of this nature imposes a large and
expensive load on the hosts of every system on the spam list. Why do you
think that those who are paying the costs should subsidize this unsavory
and unethical practice?
Received: from ietf.org by ietf.org id aa14818; 27 Feb 97 9:32 EST
Received: from hail.ncr.disa.mil by ietf.org id aa14751; 27 Feb 97 9:30 EST
Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id JAA07136; Thu, 27 Feb 1997 09:26:24 -0500 (EST)
Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01)
id AA857064429; Thu, 27 Feb 97 09:25:31 EST
Date: Thu, 27 Feb 97 09:25:31 EST
Sender:ietf-request at ietf.org
From: Bill Flanigan <flanigab at ncr.disa.mil>
Message-Id: <9701278570.AA857064429 at ncr.disa.mil>
To: "T.P.Brisco" <brisco at iconnet.net>
Cc: ietf at ietf.org, woja at media.mit.edu, flanigab at ncr.disa.mil
Subject: Re[2]: 38th IETF Meeting...Hotel Gripe
Source-Info: From (or Sender) name not authenticated.
Hello Tom,
1. Recommend you get the AAA Tour Book for Tennessee--it list and rates
about forty in "Greater "Memphis."
2. List for downtown (all have 901 area code):
a. Best Western (two diamonds) 948-9005;
b. Comfort Inn (three) 526-0583;
c. Days Inn (two) 527-4100;
d. Holiday Inn (three) 527-7300;
e. Another Holiday Inn (three) 525-5491; and
f. Radison (three) 528-1800.
3. Rack rates for the above range from $50 to $109 before AAA (or
other) discounts.
Bill Flanigan
______________________________ Reply Separator _________________________________
Subject: Re: 38th IETF Meeting...Hotel Gripe
Author: "T.P.Brisco" <brisco at IConNet.NET> at smtp
Date: 2/26/97 11:11 AM
Can someone post a handful of nearby hotels? The lady
at registration wasn't much help ....
Tom
On Tue, 25 Feb 1997, Bill Flanigan wrote:
> Hello Roger,
>
> Maybe you're lucky--well, sort of.
>
> After all, this is Memphis TN (not Memphis, Egypt or Mars) where
> the going rates for hotels/motor inns/motels is in the $50-60
> range--AAA, e.g., lists about 25 (with three-diamond ratings) in that
> price range including a number within brisk-walking distance of the
> Peabody.
Received: from ietf.org by ietf.org id aa15364; 27 Feb 97 9:42 EST
Received: from hail.ncr.disa.mil by ietf.org id aa15280; 27 Feb 97 9:40 EST
Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id JAA07432; Thu, 27 Feb 1997 09:36:39 -0500 (EST)
Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01)
id AA857065038; Thu, 27 Feb 97 09:35:49 EST
Date: Thu, 27 Feb 97 09:35:49 EST
Sender:ietf-request at ietf.org
From: Bill Flanigan <flanigab at ncr.disa.mil>
Message-Id: <9701278570.AA857065038 at ncr.disa.mil>
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Cc: ietf at ietf.org, woja at media.mit.edu, flanigab at ncr.disa.mil
Subject: Re[2]: 38th IETF Meeting...Hotel Gripe
Source-Info: From (or Sender) name not authenticated.
Hello Ted,
Here a few other things you might want to ponder:
1. When I've negotiated with "four star" downtown hotels (BTW, my
team always includes a lawyer), the issue usually boils down to
how many room will I guarantee for how many night at a specific
rate to get the number of meeting rooms I need FOR FREE.
2. Let's assume that 2,000 IETFers pay to attend (and show up) at
an average of $270 a head. This yields $540K. Let's also assume that
the cost of the food and beverages is $5.00 per day per person for 4.5
days plus $20.00 per person for the cash-bar reception. This totals
$85K. Net profit, therefore, is $540K less $85K or $455K. This
represents a "surplus fee" of $228 paid by each attendee. Any idea
where this money ends up? I have some.
3. Let's further assume that the lowest below-the-rack-rate that
the Peaboy will go for (which I doubt is really the case) to make
their profit target is ($119 +129)/2 + $119, or $124. If attendees
pay a registration fee of $270 less $228 or $42, this allows them to
effectively stay at the Peaboy for five nights at $74 per night ($124
less $228/5). Now the Peabody's rates suddenly become not so
outrageous.
Best regards,
Bill Flanigan
______________________________ Reply Separator _________________________________
Subject: Re: 38th IETF Meeting...Hotel Gripe
Author: "Theodore Y. Ts'o" <tytso at MIT.EDU> at smtp
Date: 2/26/97 11:26 AM
Date: Tue, 25 Feb 97 17:39:20 EST
From: Bill Flanigan <flanigab at ncr.disa.mil>
Naturally, this can't help, but make me a bit curious about who (if
anyone) is seriously negotiating these rates, and what criteria (if
any) are being used?
IETF attendance is now so large that advance-booking guarantees to
completely fill many hotels in an area (even a year in advance) is
virtually riskless. This should put the IETF hotel-booking folks
firmly in the driver's seat as far as getting the lowest possible room
rate in the meeting hotel and others in the area.
Actually, we have a similar problem to USENIX. The number of meeting
and breakout rooms that we need is extremely small compared to the
number of attendees we have (read: number of paying hotel rooms). Thus,
the number of sites where we can meet are quite limited.
This does make me wonder why there were so few rooms reserved at the
IETF block rate, though. Unless the hotel was hoping that enough other
people would pay the full rate after the IETF block was exhausted,
instead of staying at the $50-$60 motel that's 1/4 mile away....
- Ted
Received: from ietf.org by ietf.org id aa16542; 27 Feb 97 9:59 EST
Received: from www.atr.net by ietf.org id aa16349; 27 Feb 97 9:57 EST
Received: from www.atr.net (www.atr.net [206.232.44.253]) by warp.atr.net (NTMail 3.02.10) with ESMTP id wa000230 for <ietf at ietf.org>; Thu, 27 Feb 1997 12:00:20 +0000
Message-ID: <3315BDA4.6789 at atr.net>
Date: Thu, 27 Feb 1997 12:00:20 -0500
Sender:ietf-request at ietf.org
From: Turner W Rentz III <treyr at atr.net>
Reply-To: treyr at atr.net
Organization: Advance Technology and research, Inc.
X-Mailer: Mozilla 3.01 (WinNT; I)
MIME-Version: 1.0
To: ietf at ietf.org
Subject: A legal argument against SPAM
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Info: Evaluation version at warp.atr.net
Source-Info: From (or Sender) name not authenticated.
My math teacher once told me
"you've got to learn to talk like a lawyer."
Here's an armchair law student's proof that
spamming is against the law in the State of
Oregon.
1. Unsolicited (marketing) telephone calls are against the law.
2. The wording of the law refers to these calls as 'communication by
telephony'
3. Email accessed by modem is 'communication by telephony'.
Therefore, unsolicited (marketing) email received over a modem is
against the law. Spam is unsolicited email sent over a modem. Therefore,
Spam is against the law. Q.E.D.
A precedent can be set in this state, with others to follow.
Telemarketing is not against the law everywhere, unfortunately :(
Received: from ietf.org by ietf.org id aa16966; 27 Feb 97 10:05 EST
Received: from ietf.ietf.org by ietf.org id aa16205; 27 Feb 97 9:56 EST
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-klyne-addressing-00.txt
Date: Thu, 27 Feb 1997 09:56:00 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9702270956.aa16205 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : E-mail addressing: the worst of all worlds?
Author(s) : G. Klyne
Filename : draft-klyne-addressing-00.txt
Pages : 5
Date : 02/26/1997
This memo is a critique of Internet e-mail addressing, with particular
reference to its suitability for use in a general purpose interpersonal
communication medium as opposed to its present use largely within a
restricted community.
The critique focusses on the differences between e-mail addresses
and other forms of addressing with which very many lay people are
intimately familiar.
This memo does not offer any solutions to the issues raised; rather
it is hoped to provoke some debate on the matter. The author would be
particularly interested in views from those whose natural language
does not use the Roman (western) alphabet.
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-klyne-addressing-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-klyne-addressing-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-klyne-addressing-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: <19970226093439.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-klyne-addressing-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-klyne-addressing-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970226093439.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16970; 27 Feb 97 10:05 EST
Received: from ietf.ietf.org by ietf.org id aa16238; 27 Feb 97 9:56 EST
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-kwan-proxy-client-conf-00.txt
Date: Thu, 27 Feb 1997 09:56:09 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9702270956.aa16238 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : DHCP Option for Proxy Client Configuration File
Author(s) : S. Kwan
Filename : draft-kwan-proxy-client-conf-00.txt
Pages : 3
Date : 02/26/1997
Application-level gateways are used on networks to provide controlled
access to the Internet. Clients in those networks must be configured
with the name or address of available proxy servers, the list of local
domain names, and other proxy client configuration information before
they can access the Internet. The defacto method of proxy client
configuration is the download of a script or configuration file
named by a URL. This document describes a DHCP option in which to
transmit this URL to a proxy client.
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-kwan-proxy-client-conf-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-kwan-proxy-client-conf-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-kwan-proxy-client-conf-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: <19970226102558.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-kwan-proxy-client-conf-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-kwan-proxy-client-conf-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970226102558.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16974; 27 Feb 97 10:05 EST
Received: from ietf.ietf.org by ietf.org id aa16279; 27 Feb 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rmonmib 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-rmonmib-hcrmon-00.txt
Date: Thu, 27 Feb 1997 09:56:21 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9702270956.aa16279 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 Remote Network Monitoring
Working Group of the IETF.
Title : Remote Network Monitoring Management Information Base
for High Capacity and Switched Networks
Author(s) : S. Waldbusser
Filename : draft-ietf-rmonmib-hcrmon-00.txt
Pages : 43
Date : 02/26/1997
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing remote network
monitoring devices.
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-rmonmib-hcrmon-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rmonmib-hcrmon-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-rmonmib-hcrmon-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: <19970226174200.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmonmib-hcrmon-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmonmib-hcrmon-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970226174200.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16969; 27 Feb 97 10:05 EST
Received: from ietf.ietf.org by ietf.org id aa16254; 27 Feb 97 9:56 EST
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-durand-gse+-00.txt
Date: Thu, 27 Feb 1997 09:56:13 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9702270956.aa16254 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : GSE+ - An Alternate Addressing Architecture to GSE
Author(s) : A. Durand
Filename : draft-durand-gse+-00.txt
Pages : 3
Date : 02/26/1997
This document present an alternative addressing architecture to the GSE
proposal (draft-ipng-gseaddr-00.txt) of Mike O'Dell. The basic change is
the introduction of a site identifier in the ESD.
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-durand-gse+-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-durand-gse+-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-durand-gse+-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: <19970226105118.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-durand-gse+-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-durand-gse+-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970226105118.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16971; 27 Feb 97 10:05 EST
Received: from ietf.ietf.org by ietf.org id aa16222; 27 Feb 97 9:56 EST
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-slein-www-dist-author-00.txt
Date: Thu, 27 Feb 1997 09:56:04 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9702270956.aa16222 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Requirements for Distributed Authoring and Versioning on
the World Wide Web
Author(s) : J. Slein, F. Vitali, J. Whitehead, D. Durand
Filename : draft-slein-www-dist-author-00.txt
Pages : 17
Date : 02/26/1997
Current World Wide Web (WWW or Web) standards provide simple support for
applications which allow remote editing of typed data. In practice, the
existing capabilities of the WWW have proven inadequate to support
efficient, scalable remote editing free of overwriting conflicts. This
document presents a list of features in the form of requirements which, if
implemented, would improve the efficiency of common remote editing
operations, provide a locking mechanism to prevent overwrite conflicts,
improve relationship management support between non-HTML data types,
provide a simple attribute-value metadata facility, provide for the
creation and reading of container data types, and integrate versioning
into the WWW.
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-slein-www-dist-author-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-slein-www-dist-author-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-slein-www-dist-author-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: <19970226104148.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-slein-www-dist-author-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-slein-www-dist-author-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970226104148.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25510; 27 Feb 97 11:21 EST
Received: from mailhost.worldnet.att.net by ietf.org id aa25194;
27 Feb 97 11:17 EST
Received: from LOCALNAME ([207.146.160.192]) by mtigwc02.worldnet.att.net
(post.office MTA v2.0 0613 ) with SMTP id AAA2962
for <ietf at ietf.org>; Thu, 27 Feb 1997 16:14:43 +0000
X-Sender: PJJ.PC at postoffice.worldnet.att.net
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: PJJ.PC at worldnet.att.net
Subject: Remove us from the mailing list
Date: Thu, 27 Feb 1997 16:14:43 +0000
Message-ID: <19970227161441.AAA2962 at LOCALNAME>
Source-Info: From (or Sender) name not authenticated.
To whom it may concern,
We are a law firm in Chicago. Somehow you have managed to get us on
a mailing list for some organization we do not belong to. We are now
receiving at least 20 messages a day with information nobody has any use
for. Please remove us form this list as soon as you receive this message.
If this is not the correct adress for which I can talk to about removing us
form the list can you please refer me to it.
Thank You
Ms. SMH
for PJJ.PC
Received: from ietf.org by ietf.org id aa00532; 27 Feb 97 12:55 EST
Received: from icicle.winternet.com by ietf.org id aa00404; 27 Feb 97 12:51 EST
Received: (from adm at localhost) by icicle.winternet.com (8.7.5/8.7.5) id LAA19787 for <ietf at ietf.org>; Thu, 27 Feb 1997 11:49:17 -0600 (CST)
Posted-Date: Thu, 27 Feb 1997 11:49:17 -0600 (CST)
Received: from mackie.winternet.com(204.246.64.78) by icicle.winternet.com via smap (V2.0beta)
id xma019770; Thu, 27 Feb 97 11:48:59 -0600
Received: from www.interact-net.com by www.interact-net.com (NTMail 3.02.10) with ESMTP id da000081 for <ietf at ietf.org>; Thu, 27 Feb 1997 11:57:22 +0000
Received: by localhost with Microsoft Mail
id <01BC24A5.634B6320 at localhost>; Thu, 27 Feb 1997 11:57:21 -0600
Message-ID: <01BC24A5.634B6320 at localhost>
Sender:ietf-request at ietf.org
From: Jon Davis <jon at interact-net.com>
To: "ietf at ietf.org" <ietf at ietf.org>
Date: Thu, 27 Feb 1997 11:16:32 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Info: Evaluation version at www.interact-net.com
Source-Info: From (or Sender) name not authenticated.
Someone please remove me from this list
Thanks
Received: from ietf.org by ietf.org id aa00879; 27 Feb 97 13:02 EST
Received: from black-ice.gateway.com by ietf.org id aa00714; 27 Feb 97 13:00 EST
Received: from localhost (abc at localhost) by station1.firehouse.net (8.8.4/Not quite) with SMTP id MAA01163 for <ietf at ietf.org>; Thu, 27 Feb 1997 12:57:31 -0500 (EST)
Date: Thu, 27 Feb 1997 12:57:30 -0500 (EST)
Sender:ietf-request at ietf.org
From: Alan Clegg <abc at firehouse.net>
To: ietf at ietf.org
Subject: Revelation caused by [Re: Remove us from the mailing list]
In-Reply-To: <19970227161441.AAA2962 at LOCALNAME>
Message-ID: <Pine.BSI.3.95.970227125418.1096A-100000 at station1.firehouse.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Thu, 27 Feb 1997 PJJ.PC at worldnet.att.net wrote:
> We are now
>receiving at least 20 messages a day with information nobody has any use
>for.
Oddly enough, this boils right down to the problem at the heart of the
Internet these days, does it not?
-abc
|
The Internet is not for sissies. [paul at vix.com] | Alan Clegg
|
Received: from ietf.org by ietf.org id aa00882; 27 Feb 97 13:02 EST
Received: from iggy.iwsc.com by ietf.org id aa00760; 27 Feb 97 13:00 EST
Received: from bmeandzija_nt (analog_dell.gi.com [168.84.65.19])
by iggy.iwsc.com (post.office MTA v1.9.3 ID# 10-12202) with SMTP
id AAA252; Thu, 27 Feb 1997 10:03:03 -0800
Message-ID: <3315C996.1186 at metacomm.com>
Date: Thu, 27 Feb 1997 09:51:18 -0800
Sender:ietf-request at ietf.org
From: Branislav Meandzija <bran at metacomm.com>
Reply-To: bran at metacomm.com
Organization: Meta Communications, Inc.
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: thomas keller <tkeller at unlinfo2.unl.edu>
CC: "Theodore Y. Ts'o" <tytso at mit.edu>,
Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
Subject: Re: don't shoot the messenger
References: <Pine.3.89.9702270719.A354-0100000 at unlinfo2.unl.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
thomas keller wrote:
>
> On Wed, 26 Feb 1997, Branislav Meandzija wrote:
> > Theodore Y. Ts'o wrote:
> > > Date: Wed, 26 Feb 1997 09:04:01 -0500
> > > From: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
> > > I'd say: get all the spammers to sign up with one spam-only provider,
> > > find out what IP range they got and add a capability to sendmail to
> > > block that range. Unlike, say, netcom, you don't have to worry about
> > > blocking the mail of innocent bystanders.
> >>> MIT has already put that feature (an access list for incoming IP
> >>> addresses/subnets) in our sendmail hubs.....
> >>>> To me this looks too much like censorship. I'll rather be my own
> >>>> censor.
>
> Censorship? Hardly. Spamming of this nature imposes a large and
> expensive load on the hosts of every system on the spam list. Why do you
> think that those who are paying the costs should subsidize this unsavory
> and unethical practice?
They shouldn't but neither should anybody without the recipient's
explicit permission cut the recipient off from a part of the wild, wild,
west. For example, do all the people at MIT know that Theodore Y. is
cutting them off from whoever the suspected (remember, in dubio pro rei,
I belive) spammers are.
Branislav
Received: from ietf.org by ietf.org id aa07617; 27 Feb 97 15:29 EST
Received: from apprentice.qualcomm.com by ietf.org id aa07471;
27 Feb 97 15:24 EST
Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id MAA25654; Thu, 27 Feb 1997 12:22:32 -0800 (PST)
X-Sender: jwn2 at mage.qualcomm.com
Message-Id: <v0310170faf3b9b02d74c at [129.46.166.223]>
In-Reply-To: <3315BDA4.6789 at atr.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Eudora [Macintosh version 3.1b23-3.97]
X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57
Date: Thu, 27 Feb 1997 12:15:04 -0800
To: treyr at atr.net
Sender:ietf-request at ietf.org
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
Subject: Re: A legal argument against SPAM
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 12:00 PM -0500 2/27/97, Turner W Rentz III wrote:
>My math teacher once told me
>"you've got to learn to talk like a lawyer."
>
>
>Here's an armchair law student's proof that
>spamming is against the law in the State of
>Oregon.
>
So somebody in Oregon want to haul Cyber Promotions into court to see if
this stands up?
john noerenberg
jwn2 at qualcomm.com
--------------------------------------------------------------------
She discovered, as many a living being had discovered, that
rational decisions are far more easily made than carried out.
-- Orson Scott Card, Speaker for the Dead, 1986
--------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa08347; 27 Feb 97 15:48 EST
Received: from callandor.cybercash.com by ietf.org id aa08262;
27 Feb 97 15:46 EST
Received: by callandor.cybercash.com; id PAA11988; Thu, 27 Feb 1997 15:34:18 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma011963; Thu, 27 Feb 97 15:33:52 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA14572; Thu, 27 Feb 97 15:39:37 EST
Date: Thu, 27 Feb 1997 15:39:36 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: ietf at ietf.org
Subject: Re: Remove us from the mailing list
Message-Id: <Pine.SUN.3.91.970227153007.13158E-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Hi,
Forging people's names on subscriptions to mailing lists is becoming a daily
occurance. Spamming is becoming an hourly occurance.
The IETF list needs stronger control than it apparently has. For example:
at a minimum, only allow posting from people on the list (or on a separate
list you maintain so people who post from multiple addresses don't have too
much inconvenience) and no one should be added to the list unless at least an
email loop confirmation occurs where you send mail asking for a confirmation
of the subscritpion request and get back a postitive response from the
subscription address.
I'm not saying such measures will eliminate all problems, but I think
they will help a lot.
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
---------- Forwarded message ----------
Date: Thu, 27 Feb 1997 16:14:43 +0000
From: PJJ.PC at worldnet.att.net
To: ietf at ietf.org
Subject: Remove us from the mailing list
To whom it may concern,
We are a law firm in Chicago. Somehow you have managed to get us on
a mailing list for some organization we do not belong to. We are now
receiving at least 20 messages a day with information nobody has any use
for. Please remove us form this list as soon as you receive this message.
If this is not the correct adress for which I can talk to about removing us
form the list can you please refer me to it.
Thank You
Ms. SMH
for PJJ.PC
Received: from ietf.org by ietf.org id aa08970; 27 Feb 97 15:58 EST
Received: from lynx.europe.shiva.com by ietf.org id aa08693; 27 Feb 97 15:56 EST
Received: from chryses.europe.shiva.com (chryses.europe.shiva.com [89.0.0.223])
by lynx.europe.shiva.com (8.8.5/8.8.5) with ESMTP id UAA13709;
Thu, 27 Feb 1997 20:53:38 GMT
Received: from black.europe.shiva.com (black.europe.shiva.com [134.191.8.140])
by chryses.europe.shiva.com (8.8.5/8.8.5) with SMTP id UAA09014;
Thu, 27 Feb 1997 20:53:37 GMT
Received: from localhost by black.europe.shiva.com (SMI-8.6/SMI-SVR4)
id UAA11465; Thu, 27 Feb 1997 20:53:37 GMT
Date: Thu, 27 Feb 1997 20:53:36 +0000 (GMT)
Sender:ietf-request at ietf.org
From: Malcolm Campbell <malcolmc at europe.shiva.com>
To: "John W. Noerenberg" <jwn2 at qualcomm.com>
cc: treyr at atr.net, ietf at ietf.org
Subject: Re: A legal argument against SPAM
In-Reply-To: <v0310170faf3b9b02d74c at [129.46.166.223]>
Message-ID: <Pine.GSO.3.95.970227205133.11463A-100000 at black.europe.shiva.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Thu, 27 Feb 1997, John W. Noerenberg wrote:
> So somebody in Oregon want to haul Cyber Promotions into court to see if
> this stands up?
I havent a clue about US law, being neither American, nor a lawyer - but
someone sent me this as a suggested reply to junk mailers...
----
Under USC 47 Sec.227(b)(1)(C):
"It shall be unlawful for any person within the United States to
use any telephone facsimile machine, computer, or other device
to send an unsolicited advertisement to a telephone facsimile
machine"
where a "telephone facsimile machine" is defined in Sec.227(a)(2)(B) as:
"equipment which has the capacity to transcribe text or images
(or both) from an electronic signal received over a regular
telephone line onto paper."
Note that under this definition, my e-mail account, modem, computer
and printer constitute a fax machine.
Under Sec.227(b)(3)(B):
"A person or entity may, if otherwise permitted by the laws or
rules of court of a State, bring in an appropriate court of
that State -
(A) an action based on a violation of this subsection or the
regulations prescribed under this subsection to enjoin
such violation,
(B) an action to recover for actual monetary loss from such a
violation, or to receive $500 in damages for each such
violation, whichever is greater, or
(C) both such actions. If the court finds that the defendant
willfully or knowingly violated this subsection or the
regulations prescribed under this subsection, the court
may, in its discretion, increase the amount of the award
to an amount equal to not more than 3 times the amount
available under subparagraph (B) of this paragraph."
Received: from ietf.org by ietf.org id aa08969; 27 Feb 97 15:58 EST
Received: from apprentice.qualcomm.com by ietf.org id aa08748;
27 Feb 97 15:56 EST
Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id MAA29998; Thu, 27 Feb 1997 12:53:45 -0800 (PST)
X-Sender: jwn2 at mage.qualcomm.com
Message-Id: <v03101711af3b9c9535ec at [129.46.166.223]>
In-Reply-To: <Pine.3.89.9702270719.A354-0100000 at unlinfo2.unl.edu>
References: <3314797F.36C at metacomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Eudora [Macintosh version 3.1b23-3.97]
X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57
Date: Thu, 27 Feb 1997 12:32:54 -0800
To: thomas keller <tkeller at unlinfo2.unl.edu>
Sender:ietf-request at ietf.org
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
Subject: Re: don't shoot the messenger
Cc: Branislav Meandzija <bran at metacomm.com>,
"Theodore Y. Ts'o" <tytso at mit.edu>,
Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 7:59 AM -0600 2/27/97, thomas keller wrote:
>On Wed, 26 Feb 1997, Branislav Meandzija wrote:
>> Theodore Y. Ts'o wrote:
>> > Date: Wed, 26 Feb 1997 09:04:01 -0500
>>>> MIT has already put that feature (an access list for incoming IP
>>>> addresses/subnets) in our sendmail hubs.....
>>>>> To me this looks too much like censorship. I'll rather be my own
>>>>> censor.
>
> Censorship? Hardly. Spamming of this nature imposes a large and
>expensive load on the hosts of every system on the spam list. Why do you
>think that those who are paying the costs should subsidize this unsavory
>and unethical practice?
But, Tom, by what rule can you say this is unsavory and unethical? Where
is the privileged position that enables you (or anyone else) to impose the
judgement this is morally unjustified?
I find the idea of a suit intriguing, because a judgement against Cyber
Promotions would say their practice is socially unacceptable. But that's
different than imposing a moral choice.
Personally, I agree with Branislav. But...
We don't do morals, and we don't do social conventions. We do technology here.
What is the proof that spamming necessarily imposes a large and expensive
load on the hosts involved?
john noerenberg
jwn2 at qualcomm.com
--------------------------------------------------------------------
She discovered, as many a living being had discovered, that
rational decisions are far more easily made than carried out.
-- Orson Scott Card, Speaker for the Dead, 1986
--------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa10550; 27 Feb 97 16:24 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa10320; 27 Feb 97 16:22 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id QAA29514;
Thu, 27 Feb 1997 16:19:30 -0500
Message-Id: <199702272119.QAA29514 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Malcolm Campbell <malcolmc at europe.shiva.com>
Cc: "John W. Noerenberg" <jwn2 at qualcomm.com>, treyr at atr.net, ietf at ietf.org
Subject: Re: A legal argument against SPAM
In-Reply-To: Your message of "Thu, 27 Feb 1997 20:53:36 GMT."
<Pine.GSO.3.95.970227205133.11463A-100000 at black.europe.shiva.com>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <Pine.GSO.3.95.970227205133.11463A-100000 at black.europe.shiva.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-353772832P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Thu, 27 Feb 1997 16:19:29 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-353772832P
Content-Type: text/plain; charset=us-ascii
On Thu, 27 Feb 1997 20:53:36 GMT, Malcolm Campbell said:
> Note that under this definition, my e-mail account, modem, computer
> and printer constitute a fax machine.
Umm.. don't go there. Really. You're opening a can of worms.
If you try to chase this on the grounds that e-mail is Fax, then you're
going to have to *also* deal with some of the fax-specific things - isn't
there a requirement that the originating site/phone number appear at
the top/bottom of each page of the fax, etc?
A better bet is to just live with the situation, and lobby your local
Congresscreature (or equivalent for those outside the US) to get legislation
passed that actually matches the technology, and the problems involved.
This is far from easy to get right - in fact, the *Department of Justice*
filed a brief *opposing* the original Exon amendment, because the way it
re-defined electronic communication, it *removed* all enforcement
ability of *current* legislation.
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_-353772832P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMxX6XtQBOOoptg9JAQF/+gP/eUFRHOpEwdvc2tHA5xyFw5hoF+R+97Pm
djLcZwWqV1zIaRR5KFUW49ZJLrKwPGVR/D3qV5Ri4kG94pB0/L7dll1FEuymI2kJ
l4fw/UllWFAdF+kE0vk+dNAkobp0K97442RpzZYeizjNxKODnNZc1hniFyBZPZEP
9q6HWFJd0Bk=
=wZiw
-----END PGP MESSAGE-----
--==_Exmh_-353772832P--
Received: from ietf.org by ietf.org id aa10909; 27 Feb 97 16:31 EST
Received: from gateway-gw.pictel.com by ietf.org id aa10792; 27 Feb 97 16:28 EST
Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740)
id AA06202; Thu, 27 Feb 97 16:25:55 EST
Received: from smtpnotes.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1)
id AA17810; Thu, 27 Feb 97 16:25:54 EST
Received: by smtpnotes.pictel.com (4.1/SMI-4.1)
id AA16551; Thu, 27 Feb 97 16:25:52 EST
Message-Id: <9702272125.AA16551 at smtpnotes.pictel.com>
Received: from PicTel with "Lotus Notes Mail Gateway for SMTP" id
F8869DB2EFDC46EC8525644B007564BC; Thu, 27 Feb 97 21:25:52
To: ietf <ietf at ietf.org>
Sender:ietf-request at ietf.org
From: Bradley Stevenson/Engineering/PicTel <Bradley_Stevenson at smtpnotes.pictel.com>
Date: 27 Feb 97 16:22:49 EDT
Subject: remove
Mime-Version: 1.0
Content-Type: Text/Plain
Source-Info: From (or Sender) name not authenticated.
remove
unsubscribe
take me off this list
Received: from ietf.org by ietf.org id aa14707; 27 Feb 97 17:18 EST
Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa14567;
27 Feb 97 17:16 EST
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA05432; Thu, 27 Feb 97 17:12:49 EST
Received: by dcl.MIT.EDU (5.x/4.7) id AA18017; Thu, 27 Feb 1997 17:12:43 -0500
Date: Thu, 27 Feb 1997 17:12:43 -0500
Message-Id: <9702272212.AA18017 at dcl.MIT.EDU>
Sender:ietf-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: "John W. Noerenberg" <jwn2 at qualcomm.com>
Cc: thomas keller <tkeller at unlinfo2.unl.edu>,
Branislav Meandzija <bran at metacomm.com>,
"Theodore Y. Ts'o" <tytso at mit.edu>,
Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
In-Reply-To: John W. Noerenberg's message of Thu, 27 Feb 1997 12:32:54 -0800,
<v03101711af3b9c9535ec at [129.46.166.223]>
Subject: Re: don't shoot the messenger
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Source-Info: From (or Sender) name not authenticated.
Date: Thu, 27 Feb 1997 12:32:54 -0800
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
What is the proof that spamming necessarily imposes a large and expensive
load on the hosts involved?
That's been our experience at MIT. We get the gamut between people
sending SPAM to our users, which cause them to complain to postmaster,
to people using MIT.EDU has a large-sclae SPAM reflector, to people
sending e-mail bombs through MIT.EDU. Throughout all of this do not
underestimate the amount of time it takes to handle user complaints
which get sent to postmaster.
It's those reasons in particular why we ultimately ended up implementing
IP-level blocking. One can debate whether or not users actually want to
receive the spam, but if the spam is endangering their ability to get
fast reliable mail access, blocking it so that they can get their normal
mail does seem to be what our users want.
- Ted
Received: from ietf.org by ietf.org id aa15270; 27 Feb 97 17:24 EST
Received: from [151.145.250.198] by ietf.org id aa15164; 27 Feb 97 17:22 EST
Received: (from smap at localhost) by eagle.anheuser-busch.com (8.7.5/8.6.12) id QAA14882 for <ietf at ietf.org>; Thu, 27 Feb 1997 16:11:27 -0600 (CST)
Received: from stlabcexg001.anheuser-busch.com(151.145.101.151) by eagle.anheuser-busch.com via smap (V1.3)
id sma014876; Thu Feb 27 16:11:00 1997
Received: by stlabcexg001.anheuser-busch.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
id <01BC24C9.EC2A8FD0 at stlabcexg001.anheuser-busch.com>; Thu, 27 Feb 1997 16:18:52 -0600
Message-ID: <c=US%a=attmail%p=BUSCH%l=STLABCEXG01-970227221847Z-116066 at stlabcexg001.anheuser-busch.com>
Sender:ietf-request at ietf.org
From: "Rabb, Daniel" <Daniel.Rabb at anheuser-busch.com>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: Do you want off this Mailing List ? (From www.ietf.org)
Date: Thu, 27 Feb 1997 16:18:47 -0600
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
To join the announcement list, send a request to:
ietf-announce-request at ietf.org
and enter the word subscribe in the Subject line of the message.
The IETF discussion list is open, and therefore has a wide range of
topics. However, be advised that employment opportunities and
advertising
fall well outside the range of acceptable topics.
To join the IETF general discussion list, send a request to:
ietf-request at ietf.org
and enter the word subscribe in the Subject line of the message.
An archive of mail sent to the IETF lists is available via anonymous FTP
from the directory /ietf-mail-archive/ietf on ietf.org.
To join most other Internet mailing lists, send a request to the
associated ``-request'' address (e.g., to join the list at listhost list,
send a message to list-request at listhost). Never send a subscription
message to the list itself.
General inquiries about the IETF should be sent to ietf-info at ietf.org .
-------------
In other words.. to unsubscribe yourself from this list please send a
message to ietf-request at ietf.org and enter the word unsubscribe in the
Subject line of the message.
PLEASE do not send requests to unsubsribe from this list, to the list
itself.
Thank you,
Dan Rabb
Communications and Network Services
314/865-9149
Daniel.Rabb at Anheuser-Busch.com
Received: from ietf.org by ietf.org id aa16073; 27 Feb 97 17:37 EST
Received: from audio.ecn.purdue.edu by ietf.org id aa15861; 27 Feb 97 17:34 EST
Received: from audio.ecn.purdue.edu (ali at localhost)
by audio.ecn.purdue.edu (8.6.12/3.8davy)
for delivery to "ietf at ietf.org"
id RAA20885; Thu, 27 Feb 1997 17:32:02 -0500
Message-Id: <199702272232.RAA20885 at audio.ecn.purdue.edu>
Date: Thu, 27 Feb 1997 17:32:02 -0500
Sender:ietf-request at ietf.org
From: Zafar Ali <ali at ecn.purdue.edu>
To: ietf at ietf.org
Subject: remove
Source-Info: From (or Sender) name not authenticated.
remove
unsubscribe
Received: from ietf.org by ietf.org id aa17967; 27 Feb 97 17:59 EST
Received: from apprentice.qualcomm.com by ietf.org id aa17828;
27 Feb 97 17:57 EST
Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id OAA19783; Thu, 27 Feb 1997 14:51:59 -0800 (PST)
X-Sender: jwn2 at mage.qualcomm.com
Message-Id: <v03101719af3bb8a2cc98 at [129.46.166.223]>
In-Reply-To: <Pine.SUN.3.91.970227153007.13158E-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Eudora [Macintosh version 3.1b23-3.97]
X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57
Date: Thu, 27 Feb 1997 14:28:09 -0800
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
Sender:ietf-request at ietf.org
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
Subject: Re: Remove us from the mailing list
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 3:39 PM -0500 2/27/97, Donald E. Eastlake 3rd wrote:
>
>The IETF list needs stronger control than it apparently has. For example:
>at a minimum, only allow posting from people on the list (or on a separate
>list you maintain so people who post from multiple addresses don't have too
>much inconvenience)
Just because a list is public and membership unrestricted, why should that
imply posters cannot be anonymous?
>and no one should be added to the list unless at least an
>email loop confirmation occurs where you send mail asking for a confirmation
>of the subscritpion request and get back a postitive response from the
>subscription address.
What policy would your propose for subscriber addresses that are themselves
public lists with unrestricted membership?
john noerenberg
jwn2 at qualcomm.com
--------------------------------------------------------------------
She discovered, as many a living being had discovered, that
rational decisions are far more easily made than carried out.
-- Orson Scott Card, Speaker for the Dead, 1986
--------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa19686; 27 Feb 97 18:20 EST
Received: from also.media.org by ietf.org id aa19609; 27 Feb 97 18:18 EST
Received: (from carl at localhost)
by also.media.org (8.8.5/8.8.4/961211bjb)
id SAA24523; Thu, 27 Feb 1997 18:16:01 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Carl Malamud [IMS]" <carl at also.media.org>
Message-Id: <199702272316.SAA24523 at also.media.org>
Subject: Re: don't shoot the messenger
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Date: Thu, 27 Feb 1997 18:16:01 -0500 (EST)
Cc: jwn2 at qualcomm.com, tkeller at unlinfo2.unl.edu, bran at metacomm.com,
tytso at mit.edu, schulzrinne at cs.columbia.edu, cnielsen at pbi.net,
ietf at ietf.org
In-Reply-To: <9702272212.AA18017 at dcl.MIT.EDU> from "Theodore Y. Ts'o" at Feb 27, 97 05:12:43 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 agree with Ted ... there is a very strong and very real cost
to spamming and mailbombing. When Santa was mailbombed at
north.pole.org, we had three people working for a a week
doing nothing but handle the situation. Likewise with spamming,
a problem we had with tpc.int where people decided they
had to fax 500 copies of a notice to 500 members of congress.
IP level blocking was the only serious way to handle these
problems. DNS blocks in sendmail or inetd were partially
effective, but we found folks that spend their time damaging
the world also tend not to have very effective network
implementations (e.g., their dns tables are inevitably screwed
up).
We weren't an ISP, merely a content provider, and I can tell
you we felt the costs in no uncertain terms.
Carl
According to Theodore Y. Ts'o:
>
> Date: Thu, 27 Feb 1997 12:32:54 -0800
> From: "John W. Noerenberg" <jwn2 at qualcomm.com>
>
> What is the proof that spamming necessarily imposes a large and expensive
> load on the hosts involved?
>
> That's been our experience at MIT. We get the gamut between people
> sending SPAM to our users, which cause them to complain to postmaster,
> to people using MIT.EDU has a large-sclae SPAM reflector, to people
> sending e-mail bombs through MIT.EDU. Throughout all of this do not
> underestimate the amount of time it takes to handle user complaints
> which get sent to postmaster.
>
> It's those reasons in particular why we ultimately ended up implementing
> IP-level blocking. One can debate whether or not users actually want to
> receive the spam, but if the spam is endangering their ability to get
> fast reliable mail access, blocking it so that they can get their normal
> mail does seem to be what our users want.
>
> - Ted
>
Received: from ietf.org by ietf.org id aa19807; 27 Feb 97 18:21 EST
Received: from callandor.cybercash.com by ietf.org id aa19716;
27 Feb 97 18:20 EST
Received: by callandor.cybercash.com; id SAA20549; Thu, 27 Feb 1997 18:09:09 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma020541; Thu, 27 Feb 97 18:08:57 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA18833; Thu, 27 Feb 97 18:14:42 EST
Date: Thu, 27 Feb 1997 18:14:41 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: ietf at ietf.org
Subject: Re: Remove us from the mailing list
In-Reply-To: <v03101719af3bb8a2cc98 at [129.46.166.223]>
Message-Id: <Pine.SUN.3.91.970227180639.18109B at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Thu, 27 Feb 1997, John W. Noerenberg wrote:
> Date: Thu, 27 Feb 1997 14:28:09 -0800
> From: John W. Noerenberg <jwn2 at qualcomm.com>
>
> At 3:39 PM -0500 2/27/97, Donald E. Eastlake 3rd wrote:
> >
> >The IETF list needs stronger control than it apparently has. For example:
> >at a minimum, only allow posting from people on the list (or on a separate
> >list you maintain so people who post from multiple addresses don't have too
> >much inconvenience)
>
> Just because a list is public and membership unrestricted, why should that
> imply posters cannot be anonymous?
And where did I say they couldn't be? I just indicated that they should have
to go through an explicit email loop subscription cycle. As commonly
happens, the abusers make life a bit more difficult for everyone else.
> >and no one should be added to the list unless at least an
> >email loop confirmation occurs where you send mail asking for a confirmation
> >of the subscritpion request and get back a postitive response from the
> >subscription address.
>
> What policy would your propose for subscriber addresses that are themselves
> public lists with unrestricted membership?
Such subscriptions have always been problematic due to bounces from
sublist entries going back to the main list maintainer who knows nothing
about them. I believe there are some early RFCs on this.
The existence of any lists on the general Internet with no restirction or
confirmation on subscriptions is an open inviation to abuse, abuse which is
occuring with increasing frequency. There are a variety of possible
solutions or partial solutions to the email abuse problems we are
seeing. Doing nothing is not one of these.
> john noerenberg
> jwn2 at qualcomm.com
> --------------------------------------------------------------------
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 aa20198; 27 Feb 97 18:26 EST
Received: from singapura.singnet.com.sg by ietf.org id aa19961;
27 Feb 97 18:25 EST
Received: from localhost (mathias at localhost) by singapura.singnet.com.sg (8.8.5/8.7.2) with SMTP id HAA19275; Fri, 28 Feb 1997 07:22:23 +0800 (SST)
Date: Fri, 28 Feb 1997 07:22:20 +0800 (SST)
Sender:ietf-request at ietf.org
From: Mathias Koerber <mathias at staff.singnet.com.sg>
X-Sender: mathias at singapura.singnet.com.sg
Reply-To: mathias at staff.singnet.com.sg
To: Zafar Ali <ali at ecn.purdue.edu>
cc: ietf at ietf.org
Subject: Re: remove
In-Reply-To: <199702272232.RAA20885 at audio.ecn.purdue.edu>
Message-ID: <Pine.OSF.3.93.970228072148.15902A-100000 at singapura.singnet.com.sg>
X-Disclaimer: I don't speak for anyone except for myself (and to myself sometimes)
Organization: SingNet
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Thu, 27 Feb 1997, Zafar Ali wrote:
| Date: Thu, 27 Feb 1997 17:32:02 -0500
| From: Zafar Ali <ali at ecn.purdue.edu>
| To: ietf at ietf.org
| Subject: remove
|
| remove
| unsubscribe
|
Pls send requests like this to: ietf-REQUEST at ietf.org
NOT the list itself.
Thx
Mathias Koerber | Tel: +65 / 471 9820 | mathias at staff.singnet.com.sg
SingNet NOC | Fax: +65 / 475 3273 | mathias at koerber.org
Q'town Tel. Exch. | PGP: Keyid: 768/25E082BD, finger mathias at singnet.com.sg
2 Stirling Rd | 1A 8B FC D4 93 F1 9A FC BD 98 A3 1A 0E 73 01 65
S'pore 148943 | Disclaimer: I speak only for myself
* Eifersucht ist eine Leidenschaft, die mit Eifer sucht, was Leiden schafft *
Received: from ietf.org by ietf.org id aa22248; 27 Feb 97 18:56 EST
Received: from apprentice.qualcomm.com by ietf.org id aa22141;
27 Feb 97 18:55 EST
Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id PAA00671; Thu, 27 Feb 1997 15:51:59 -0800 (PST)
X-Sender: jwn2 at mage.qualcomm.com
Message-Id: <v0310171caf3bbc2fa242 at [129.46.166.223]>
In-Reply-To: <9702272212.AA18017 at dcl.MIT.EDU>
References: John W. Noerenberg's message of Thu, 27 Feb 1997 12:32:54
-0800, <v03101711af3b9c9535ec at [129.46.166.223]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Eudora [Macintosh version 3.1b23-3.97]
X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57
Date: Thu, 27 Feb 1997 15:36:54 -0800
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Sender:ietf-request at ietf.org
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
Subject: Re: don't shoot the messenger
Cc: thomas keller <tkeller at unlinfo2.unl.edu>,
Branislav Meandzija <bran at metacomm.com>,
"Theodore Y. Ts'o" <tytso at mit.edu>,
Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 5:12 PM -0500 2/27/97, Theodore Y. Ts'o wrote:
> Date: Thu, 27 Feb 1997 12:32:54 -0800
> From: "John W. Noerenberg" <jwn2 at qualcomm.com>
>
> What is the proof that spamming necessarily imposes a large and expensive
> load on the hosts involved?
>
>That's been our experience at MIT. We get the gamut between people
>sending SPAM to our users, which cause them to complain to postmaster,
>to people using MIT.EDU has a large-sclae SPAM reflector, to people
>sending e-mail bombs through MIT.EDU. Throughout all of this do not
>underestimate the amount of time it takes to handle user complaints
>which get sent to postmaster.
That's practical experience and very valuable. Is there some conclusion
that can be drawn from the organization of store-and-forward nets that says
dropping a large bolus of spam in the net necessarily causes congestion (or
maybe indigestion is better here)? All the effects you cite are the result
of network congestion. IETF should be seeking a methodological explanation
for why spam is bad, or determine that none can be found presently. (This
is an invitation for anyone working on this problem to publicize
themselves.)
Btw, don't anybody for one minute think I actually like those cretin spammers.
john noerenberg
jwn2 at qualcomm.com
--------------------------------------------------------------------
She discovered, as many a living being had discovered, that
rational decisions are far more easily made than carried out.
-- Orson Scott Card, Speaker for the Dead, 1986
--------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa26201; 27 Feb 97 19:32 EST
Received: from icicle.winternet.com by ietf.org id aa26048; 27 Feb 97 19:30 EST
Received: (from adm at localhost) by icicle.winternet.com (8.7.5/8.7.5) id SAA08458 for <ietf at ietf.org>; Thu, 27 Feb 1997 18:27:56 -0600 (CST)
Posted-Date: Thu, 27 Feb 1997 18:27:56 -0600 (CST)
Received: from mackie.winternet.com(204.246.64.78) by icicle.winternet.com via smap (V2.0beta)
id xma008425; Thu, 27 Feb 97 18:27:31 -0600
Received: from www.interact-net.com by www.interact-net.com (NTMail 3.02.10) with ESMTP id pa000093 for <ietf at ietf.org>; Thu, 27 Feb 1997 18:35:52 +0000
Received: by mackie.winternet.com with Microsoft Mail
id <01BC24DD.0E199060 at mackie.winternet.com>; Thu, 27 Feb 1997 18:35:50 -0600
Message-ID: <01BC24DD.0E199060 at mackie.winternet.com>
Sender:ietf-request at ietf.org
From: Jon Davis <jon at interact-net.com>
To: "ietf at ietf.org" <ietf at ietf.org>
Subject: "REMOVE" function
Date: Thu, 27 Feb 1997 18:35:19 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Info: Evaluation version at www.interact-net.com
Source-Info: From (or Sender) name not authenticated.
I'm quite surprised that an internet technology based mailing list =
requires you to send "remove" requests to a separate e-mail address. =
I'm just a loser internet junkie with Windows NT and "NT Mail" and I'm =
spoiled on its ability to handle both actual messages and commands-if it =
understands the body as a command, it will perform it. If it looks like =
a command (1 or 2 words or whatever) but doesn't understand it, it =
ignores it. If it's a long message, it broadcasts it.
Considering there's about 1500 members on this list, it's a sad shame =
that "remove" in the body won't work. =20
Perhaps we should be the first to develop an artificially intelligent =
listserv server that can understand text like, "Please remove me from =
this list." It would then send a confirmation request to the sender to =
make sure removal is what he/she wants, or to broadcast it.
Whatever. The listserv server being used now is obviously archaic.
Jon Davis
NewBreed Communications
Received: from ietf.org by ietf.org id aa26202; 27 Feb 97 19:32 EST
Received: from cnri by ietf.org id aa26086; 27 Feb 97 19:30 EST
Received: from Turing.Stanford.EDU by CNRI.Reston.VA.US id aa27107;
27 Feb 97 19:30 EST
Received: from localhost (ole at localhost) by Turing.Stanford.EDU (8.8.5/8.8.3) with SMTP id QAA09678; Thu, 27 Feb 1997 16:26:45 -0800 (PST)
X-Authentication-Warning: Turing.Stanford.EDU: ole owned process doing -bs
Date: Thu, 27 Feb 1997 16:26:44 -0800 (PST)
Sender:ietf-request at ietf.org
From: "Ole J. Jacobsen" <ole at csli.stanford.edu>
X-Sender: ole at Turing.Stanford.EDU
To: ole at csli.stanford.edu
Subject: BOFs at Interop Las Vegas
Message-ID: <Pine.GSO.3.95.970227162351.8638C-100000 at Turing.Stanford.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
If you are interested in running a BOF at the next NetWorld+Interop in
May in Las Vegas, send a message to ldraper at interop.com for more info.
Ole
-----------------------------------------------------------------
Ole J. Jacobsen, Senior Technical Advisor, Interop Company,
Fax: Please don't, use e-mail instead.
E-mail: ole at csli.stanford.edu, ole at world.std.com, ole at interop.com
-----------------------------------------------------------------
Received: from ietf.org by ietf.org id aa26424; 27 Feb 97 19:35 EST
Received: from iggy.iwsc.com by ietf.org id aa26323; 27 Feb 97 19:34 EST
Received: from bmeandzija_nt (analog_dell.gi.com [168.84.65.19])
by iggy.iwsc.com (post.office MTA v1.9.3 ID# 10-12202) with SMTP
id AAA254; Thu, 27 Feb 1997 16:36:38 -0800
Message-ID: <331625D2.2160 at metacomm.com>
Date: Thu, 27 Feb 1997 16:24:50 -0800
Sender:ietf-request at ietf.org
From: Branislav Meandzija <bran at metacomm.com>
Reply-To: bran at metacomm.com
Organization: Meta Communications, Inc.
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: "John W. Noerenberg" <jwn2 at qualcomm.com>
CC: "Theodore Y. Ts'o" <tytso at mit.edu>,
thomas keller <tkeller at unlinfo2.unl.edu>,
Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
Subject: Re: don't shoot the messenger
References: John W. Noerenberg's message of Thu, 27 Feb 1997 12:32:54
-0800, <v03101711af3b9c9535ec at [129.46.166.223]> <v0310171caf3bbc2fa242 at [129.46.166.223]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
John W. Noerenberg wrote:
>
> At 5:12 PM -0500 2/27/97, Theodore Y. Ts'o wrote:
> > Date: Thu, 27 Feb 1997 12:32:54 -0800
> > From: "John W. Noerenberg" <jwn2 at qualcomm.com>
> >
> > What is the proof that spamming necessarily imposes a large and expensive
> > load on the hosts involved?
> >
> >That's been our experience at MIT. We get the gamut between people
> >sending SPAM to our users, which cause them to complain to postmaster,
> >to people using MIT.EDU has a large-sclae SPAM reflector, to people
> >sending e-mail bombs through MIT.EDU. Throughout all of this do not
> >underestimate the amount of time it takes to handle user complaints
> >which get sent to postmaster.
>
> That's practical experience and very valuable. Is there some conclusion
> that can be drawn from the organization of store-and-forward nets that says
> dropping a large bolus of spam in the net necessarily causes congestion (or
> maybe indigestion is better here)? All the effects you cite are the result
> of network congestion. IETF should be seeking a methodological explanation
> for why spam is bad, or determine that none can be found presently. (This
> is an invitation for anyone working on this problem to publicize
> themselves.)
>
> Btw, don't anybody for one minute think I actually like those cretin spammers.
>
> john noerenberg
> jwn2 at qualcomm.com
> --------------------------------------------------------------------
> She discovered, as many a living being had discovered, that
> rational decisions are far more easily made than carried out.
> -- Orson Scott Card, Speaker for the Dead, 1986
> --------------------------------------------------------------------
Perhaps what is needed is a mechanism for users to register with their
network operators what classes of e-mail (as defined by the network
operator or the IETF) they wish to receive. Those classes could allow
the selection of the type of e-mail reflectors they wish to be under.
That would solve many of the problems listed above while avoiding
censorship.
Branislav
Received: from ietf.org by ietf.org id aa28819; 27 Feb 97 20:05 EST
Received: from mercury.Sun.COM by ietf.org id aa28576; 27 Feb 97 20:03 EST
Received: from Holland.Sun.COM ([129.159.201.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA12801 for <ietf at ietf.org>; Thu, 27 Feb 1997 16:58:08 -0800
Received: from albano by Holland.Sun.COM (SMI-8.6/SMI-SVR4-sd.fkk200)
id CAA21109; Fri, 28 Feb 1997 02:01:25 +0100
Received: from glorantha.Holland.Sun.COM by albano (SMI-8.6/SMI-SVR4-se.fkk201)
id CAA28375; Fri, 28 Feb 1997 02:01:24 +0100
Received: by glorantha.Holland.Sun.COM (SMI-8.6/SMI-SVR4)
id BAA08401; Fri, 28 Feb 1997 01:58:51 +0100
Message-Id: <199702280058.BAA08401 at glorantha.Holland.Sun.COM>
Subject: re: ietf mailing list policy
To: ietf at ietf.org
Date: Fri, 28 Feb 1997 01:58:51 +0100 (MET)
Precedence: junk
In-Reply-To: <Pine.SUN.3.91.970227153007.13158E-100000 at cybercash.com> from "Donald E. Eastlake 3rd" at Feb 27, 97 03:39:36 pm
Sender:ietf-request at ietf.org
From: Henk.Langeveld at holland.sun.com
X-Mailer: ELM [version 2.4 PL22]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Donald E. Eastlake suggests stronger control on the ietf list,
and making it a closed "subscribers only" list.
Consider bouncing all messages that do not have "Cc:/To: ietf at ietf.org"
in the headers -- this would at least catch any occurrance of the
ietf being subscribed to another list.
Of course it would be naive to expect this to stop any deliberate
spammers, but it will take out many of the obvious mistakes.
Also, it should be a requirement for a mailing list to frequently post
[a pointer to] the subscription guidelines -with a Reply-To: *-request at ....
--
Henk Langeveld
Received: from ietf.org by ietf.org id aa02199; 27 Feb 97 20:50 EST
Received: from ns.jck.com by ietf.org id aa02026; 27 Feb 97 20:47 EST
Received: from tp.jck.com ("port 2935"@tp.jck.com)
by a4.jck.com (PMDF V5.1-7 #16053) with SMTP id <0E6AI64V100LYR at a4.jck.com>
for ietf at ietf.org; Thu, 27 Feb 1997 20:44:28 -0500 (EST)
Date: Thu, 27 Feb 1997 20:19:49 -0500
Sender:ietf-request at ietf.org
From: John C Klensin <klensin at mci.net>
Subject: Re: don't shoot the messenger
In-reply-to: <331625D2.2160 at metacomm.com>
X-Sender: klensin at alpha1.reston.mci.net
To: bran at metacomm.com
Cc: "John W. Noerenberg" <jwn2 at qualcomm.com>,
"Theodore Y. Ts'o" <tytso at mit.edu>,
thomas keller <tkeller at unlinfo2.unl.edu>,
Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
Message-id: <3.0.1.16.19970227201949.0aa768c0 at alpha1.reston.mci.net>
MIME-version: 1.0
X-Mailer: Windows Eudora Pro Version 3.0.1 (16)
Content-type: text/plain; charset="us-ascii"
References: <v03101711af3b9c9535ec at [129.46.166.223]>
<v0310171caf3bbc2fa242 at [129.46.166.223]>
Source-Info: From (or Sender) name not authenticated.
At 16:24 97.02.27 -0800, Branislav Meandzija wrote:
>Perhaps what is needed is a mechanism for users to register with their
>network operators what classes of e-mail (as defined by the network
>operator or the IETF) they wish to receive. Those classes could allow
>the selection of the type of e-mail reflectors they wish to be under.
>That would solve many of the problems listed above while avoiding
>censorship.
As long as you think the bulk mailers would observe the lists or
correctly-label material being send out. In a world in which some of them
have been accused of using "remove" replies to build new lists of people
who are "guaranteed" to read and respond to email, this is not an
obviously-safe assumption.
john
Received: from ietf.org by ietf.org id aa03662; 27 Feb 97 21:08 EST
Received: from iggy.iwsc.com by ietf.org id aa03440; 27 Feb 97 21:06 EST
Received: from bmeandzija_nt (analog_dell.gi.com [168.84.65.19])
by iggy.iwsc.com (post.office MTA v1.9.3 ID# 10-12202) with SMTP
id AAA245; Thu, 27 Feb 1997 18:08:42 -0800
Message-ID: <33163B65.5B73 at metacomm.com>
Date: Thu, 27 Feb 1997 17:56:53 -0800
Sender:ietf-request at ietf.org
From: Branislav Meandzija <bran at metacomm.com>
Reply-To: bran at metacomm.com
Organization: Meta Communications, Inc.
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: John C Klensin <klensin at mci.net>
CC: "John W. Noerenberg" <jwn2 at qualcomm.com>,
"Theodore Y. Ts'o" <tytso at mit.edu>,
thomas keller <tkeller at unlinfo2.unl.edu>,
Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
Subject: Re: don't shoot the messenger
References: <v03101711af3b9c9535ec at [129.46.166.223]>
<v0310171caf3bbc2fa242 at [129.46.166.223]> <3.0.1.16.19970227201949.0aa768c0 at alpha1.reston.mci.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
John C Klensin wrote:
>
> At 16:24 97.02.27 -0800, Branislav Meandzija wrote:
> >Perhaps what is needed is a mechanism for users to register with their
> >network operators what classes of e-mail (as defined by the network
> >operator or the IETF) they wish to receive. Those classes could allow
> >the selection of the type of e-mail reflectors they wish to be under.
> >That would solve many of the problems listed above while avoiding
> >censorship.
>
> As long as you think the bulk mailers would observe the lists or
> correctly-label material being send out. In a world in which some of them
> have been accused of using "remove" replies to build new lists of people
> who are "guaranteed" to read and respond to email, this is not an
> obviously-safe assumption.
>
> john
That is not what I ment. In essence, you can do the same as now but
add variations defining classes of defenses and allow those to be
user selectable.
Branislav
Received: from ietf.org by ietf.org id aa12884; 27 Feb 97 22:43 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa12497; 27 Feb 97 22:38 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id WAA24473; Thu, 27 Feb 1997 22:34:54 -0500 (EST)
Message-Id: <199702280334.WAA24473 at ig.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: Jon Davis <jon at interact-net.com>
cc: "ietf at ietf.org" <ietf at ietf.org>, moore at cs.utk.edu
Subject: Re: "REMOVE" function
In-reply-to: Your message of "Thu, 27 Feb 1997 18:35:19 CST."
<01BC24DD.0E199060 at mackie.winternet.com>
Date: Thu, 27 Feb 1997 22:34:54 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> I'm quite surprised that an internet technology based mailing list
> requires you to send "remove" requests to a separate e-mail address.
Even for lists that try to filter subscribe/unsubscribe requests from
the list traffic (mine do), having separate addresses for list traffic
and requests helps decrease the incidence of mis-handled mail.
I've seen a lot of lists that were too "smart" - e.g.
+ incorrectly guessing that an ordinary message contained commands,
attempting to process such commands, and sending replies back
to the sender rather than forwarding the message to the list.
+ incorrectly guessing that a message sent to the list was the
result of a mail loop and and silently dropping the message.
+ gratuitously deleting message headers that the list robot doesn't
recognize
+ refusing to forward the message because the list robot has a
conflicting notion of how to use the Precedence field, than
the sender did. (the right answer: don't use it at al)
+ refusing to accept mail from moore at cs.utk.edu just because I happen
to be subscribed as moore+folder at cs.utk.edu
+ gratuitously adding a reply-to field on all list traffic, effectively
preventing replies to all recipients of the subject message
+ gratuitously replacing the sender-specified reply-to field with the
list's reply-to field, thereby preventing someone from including
third parties in a conversation with the list.
+ deliberately setting the SMTP MAIL FROM address (on messages redistributed
to list members) to the address of the mailing list, (rather than the
address of the list maintainer as per RFC 1123), then trying to
distinguish nondelivery report messages from normal list traffic.
Thus not only are some legitimate messages treated as nondelivery
reports, some bounced messages aren't recognized and cause mail loops.
+ gratuitously munging the subject field to add the name of the list
(thus making it harder to read the real subject of the message in
a one-line-per-message summary of messages from that list)
Which is not to say that I disagree with you -- it's a good idea to
try to filter out things that are obviously subscribe/unsubscribe requests
(say, the ones that fit majordomo or listserv syntax). And for all I
know, this is already being done. But since this matching is necessarily
based on heuristics, it's probably better to minimize the number of
improperly blocked messages, even if that means that a few requests
slip through to the list.
But I have a lot more tolerance for the occasional subscribe/unsubscribe
message sent to a list, than I have for any of the practices listed above.
Keith
Received: from ietf.org by ietf.org id aa22267; 27 Feb 97 23:35 EST
Received: from icicle.winternet.com by ietf.org id aa22166; 27 Feb 97 23:34 EST
Received: (from adm at localhost) by icicle.winternet.com (8.7.5/8.7.5) id WAA05632 for <ietf at ietf.org>; Thu, 27 Feb 1997 22:31:32 -0600 (CST)
Posted-Date: Thu, 27 Feb 1997 22:31:32 -0600 (CST)
Received: from mackie.winternet.com(204.246.64.78) by icicle.winternet.com via smap (V2.0beta)
id xma005618; Thu, 27 Feb 97 22:31:22 -0600
Received: from www.interact-net.com by www.interact-net.com (NTMail 3.02.10) with ESMTP id sa000096 for <ietf at ietf.org>; Thu, 27 Feb 1997 22:39:52 +0000
Received: by localhost with Microsoft Mail
id <01BC24FF.24E21CF0 at localhost>; Thu, 27 Feb 1997 22:39:51 -0600
Message-ID: <01BC24FF.24E21CF0 at localhost>
Sender:ietf-request at ietf.org
From: Jon Davis <jon at interact-net.com>
To: "ietf at ietf.org" <ietf at ietf.org>
Cc: "ietf at ietf.org" <ietf at ietf.org>
Subject: RE: "REMOVE" function
Date: Thu, 27 Feb 1997 22:39:36 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Info: Evaluation version at www.interact-net.com
Source-Info: From (or Sender) name not authenticated.
Point taken, noted, proven, and known all along. You couldn't be more =
right. However, in some cases-let's use mine as an example-all of a =
sudden less than 24 hours ago I came home to find my e-mail box flooded =
with e-mail. None of it was directed to me. I looked at all the e-mail =
and didn't find a single e-mail explaining "WELCOME TO WHATEVER THE HELL =
MAILING LIST THIS IS, AND ***THIS*** IS HOW TO REMOVE YOURSELF. =
(Apparently, I had subscribed to the list a couple MONTHS ago, and =
someone-rather than something-finally managed to get me signed up. I =
never received a welcome e-mail that included explanation on removal =
procedures.) =20
I was stumped. I had no way of knowing how to remove myself. So, I did =
what I had to do-I e-mailed the list, asking for removal. Now I was =
getting TWICE the e-mail, telling me not to post to the list, which I =
had no clue I was subscribed to, and so frankly I really didn't care if =
everyone got copies of my "removal" e-mail. One of those e-mails, =
however, was a note from someone telling me that I'd been removed from =
the list, but I'd still be getting occasional updates. Fine. WHY AM I =
STILL ON THIS LIST?
So, you see, something is wrong, something is terribly wrong, and I am =
observing that there are at least two different gentlemen on this planet =
on this list who are in my shoes right now.
Now tell me, all you people who e-mailed me not to waste your e-mail =
bandwidth with my complaints, now tell me that it wasn't worth it / =
wasn't important enough to speak up on it.
Jon Davis
-----Original Message-----
From: Keith Moore [SMTP:moore at cs.utk.edu]
Sent: Thursday, February 27, 1997 9:35 PM
To: Jon Davis
Cc: ietf at ietf.org; moore at cs.utk.edu
Subject: Re: "REMOVE" function=20
> I'm quite surprised that an internet technology based mailing list
> requires you to send "remove" requests to a separate e-mail address.=20
Even for lists that try to filter subscribe/unsubscribe requests from
the list traffic (mine do), having separate addresses for list traffic
and requests helps decrease the incidence of mis-handled mail. =20
I've seen a lot of lists that were too "smart" - e.g.=20
+ incorrectly guessing that an ordinary message contained commands,
attempting to process such commands, and sending replies back
to the sender rather than forwarding the message to the list.=20
+ incorrectly guessing that a message sent to the list was the
result of a mail loop and and silently dropping the message.
+ gratuitously deleting message headers that the list robot doesn't=20
recognize
+ refusing to forward the message because the list robot has a=20
conflicting notion of how to use the Precedence field, than
the sender did. (the right answer: don't use it at al)
+ refusing to accept mail from moore at cs.utk.edu just because I happen
to be subscribed as moore+folder at cs.utk.edu
+ gratuitously adding a reply-to field on all list traffic, effectively
preventing replies to all recipients of the subject message
+ gratuitously replacing the sender-specified reply-to field with the
list's reply-to field, thereby preventing someone from including=20
third parties in a conversation with the list.
+ deliberately setting the SMTP MAIL FROM address (on messages =
redistributed
to list members) to the address of the mailing list, (rather than the=20
address of the list maintainer as per RFC 1123), then trying to=20
distinguish nondelivery report messages from normal list traffic.
Thus not only are some legitimate messages treated as nondelivery=20
reports, some bounced messages aren't recognized and cause mail loops.
+ gratuitously munging the subject field to add the name of the list
(thus making it harder to read the real subject of the message in
a one-line-per-message summary of messages from that list)
Which is not to say that I disagree with you -- it's a good idea to
try to filter out things that are obviously subscribe/unsubscribe =
requests=20
(say, the ones that fit majordomo or listserv syntax). And for all I
know, this is already being done. But since this matching is =
necessarily
based on heuristics, it's probably better to minimize the number of=20
improperly blocked messages, even if that means that a few requests
slip through to the list.
But I have a lot more tolerance for the occasional subscribe/unsubscribe =
message sent to a list, than I have for any of the practices listed =
above.
Keith
Received: from ietf.org by ietf.org id aa22862; 27 Feb 97 23:41 EST
Received: from icicle.winternet.com by ietf.org id aa22763; 27 Feb 97 23:40 EST
Received: (from adm at localhost) by icicle.winternet.com (8.7.5/8.7.5) id WAA06265 for <ietf at ietf.org>; Thu, 27 Feb 1997 22:37:36 -0600 (CST)
Posted-Date: Thu, 27 Feb 1997 22:37:36 -0600 (CST)
Received: from mackie.winternet.com(204.246.64.78) by icicle.winternet.com via smap (V2.0beta)
id xma006227; Thu, 27 Feb 97 22:37:14 -0600
Received: from www.interact-net.com by www.interact-net.com (NTMail 3.02.10) with ESMTP id ta000097 for <ietf at ietf.org>; Thu, 27 Feb 1997 22:45:39 +0000
Received: by localhost with Microsoft Mail
id <01BC24FF.F33A35B0 at localhost>; Thu, 27 Feb 1997 22:45:37 -0600
Message-ID: <01BC24FF.F33A35B0 at localhost>
Sender:ietf-request at ietf.org
From: Jon Davis <jon at interact-net.com>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: RE: "REMOVE" function
Date: Thu, 27 Feb 1997 22:45:27 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Info: Evaluation version at www.interact-net.com
Source-Info: From (or Sender) name not authenticated.
Ahem... sorry, everybody. Temper control. Long day. Forgive me, it's =
a neat list that I'd be happy to get involved in, but it kind of hit me =
by surprise without warning and I wasn't prepared for all this e-mail.
-----Original Message-----
From: Jon Davis=20
Sent: Thursday, February 27, 1997 10:40 PM
To: ietf at ietf.org
Cc: ietf at ietf.org
Subject: RE: "REMOVE" function=20
Point taken, noted, proven, and known all along. You couldn't be more =
right. However, in some cases-let's use mine as an example-all of a =
sudden less than 24 hours ago I came home to find my e-mail box flooded =
with e-mail. None of it was directed to me. I looked at all the e-mail =
and didn't find a single e-mail explaining "WELCOME TO WHATEVER THE HELL =
MAILING LIST THIS IS, AND ***THIS*** IS HOW TO REMOVE YOURSELF. =
(Apparently, I had subscribed to the list a couple MONTHS ago, and =
someone-rather than something-finally managed to get me signed up. I =
never received a welcome e-mail that included explanation on removal =
procedures.) =20
I was stumped. I had no way of knowing how to remove myself. So, I did =
what I had to do-I e-mailed the list, asking for removal. Now I was =
getting TWICE the e-mail, telling me not to post to the list, which I =
had no clue I was subscribed to, and so frankly I really didn't care if =
everyone got copies of my "removal" e-mail. One of those e-mails, =
however, was a note from someone telling me that I'd been removed from =
the list, but I'd still be getting occasional updates. Fine. WHY AM I =
STILL ON THIS LIST?
So, you see, something is wrong, something is terribly wrong, and I am =
observing that there are at least two different gentlemen on this planet =
on this list who are in my shoes right now.
Now tell me, all you people who e-mailed me not to waste your e-mail =
bandwidth with my complaints, now tell me that it wasn't worth it / =
wasn't important enough to speak up on it.
Jon Davis
-----Original Message-----
From: Keith Moore [SMTP:moore at cs.utk.edu]
Sent: Thursday, February 27, 1997 9:35 PM
To: Jon Davis
Cc: ietf at ietf.org; moore at cs.utk.edu
Subject: Re: "REMOVE" function=20
> I'm quite surprised that an internet technology based mailing list
> requires you to send "remove" requests to a separate e-mail address.=20
Even for lists that try to filter subscribe/unsubscribe requests from
the list traffic (mine do), having separate addresses for list traffic
and requests helps decrease the incidence of mis-handled mail. =20
I've seen a lot of lists that were too "smart" - e.g.=20
+ incorrectly guessing that an ordinary message contained commands,
attempting to process such commands, and sending replies back
to the sender rather than forwarding the message to the list.=20
+ incorrectly guessing that a message sent to the list was the
result of a mail loop and and silently dropping the message.
+ gratuitously deleting message headers that the list robot doesn't=20
recognize
+ refusing to forward the message because the list robot has a=20
conflicting notion of how to use the Precedence field, than
the sender did. (the right answer: don't use it at al)
+ refusing to accept mail from moore at cs.utk.edu just because I happen
to be subscribed as moore+folder at cs.utk.edu
+ gratuitously adding a reply-to field on all list traffic, effectively
preventing replies to all recipients of the subject message
+ gratuitously replacing the sender-specified reply-to field with the
list's reply-to field, thereby preventing someone from including=20
third parties in a conversation with the list.
+ deliberately setting the SMTP MAIL FROM address (on messages =
redistributed
to list members) to the address of the mailing list, (rather than the=20
address of the list maintainer as per RFC 1123), then trying to=20
distinguish nondelivery report messages from normal list traffic.
Thus not only are some legitimate messages treated as nondelivery=20
reports, some bounced messages aren't recognized and cause mail loops.
+ gratuitously munging the subject field to add the name of the list
(thus making it harder to read the real subject of the message in
a one-line-per-message summary of messages from that list)
Which is not to say that I disagree with you -- it's a good idea to
try to filter out things that are obviously subscribe/unsubscribe =
requests=20
(say, the ones that fit majordomo or listserv syntax). And for all I
know, this is already being done. But since this matching is =
necessarily
based on heuristics, it's probably better to minimize the number of=20
improperly blocked messages, even if that means that a few requests
slip through to the list.
But I have a lot more tolerance for the occasional subscribe/unsubscribe =
message sent to a list, than I have for any of the practices listed =
above.
Keith
Received: from ietf.org by ietf.org id aa12969; 28 Feb 97 4:51 EST
Received: from ecrc.de by ietf.org id aa12587; 28 Feb 97 4:46 EST
Received: from primergy.atlantikgmbh.de (primergy.atlantikgmbh.de [194.221.55.201]) by ecrc.ecrc.de (8.8.3/8.8.3/$Revision: 1.2 $) with SMTP id KAA01094 for <ietf at ietf.org>; Fri, 28 Feb 1997 10:43:38 +0100 (MET)
Received: by primergy.atlantikgmbh.de with Microsoft Exchange (IMC 4.0.837.3)
id <01BC2564.641B7690 at primergy.atlantikgmbh.de>; Fri, 28 Feb 1997 10:44:36 +0100
Message-ID: <c=DE%a=_%p=Die_Atlantik_Gru%l=PRIMERGY-970228094434Z-740 at primergy.atlantikgmbh.de>
Sender:ietf-request at ietf.org
From: J}rgen Wegner <jwegner at atlantikgmbh.de>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: membership
Date: Fri, 28 Feb 1997 10:44:34 +0100
Return-Receipt-To: <jwegner at atlantikgmbh.de>
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
please remove me from the list
J.Wegner
jwegner at atlantikgmbh.de
Received: from ietf.org by ietf.org id aa26789; 28 Feb 97 8:06 EST
Received: from relay.hq.tis.com by ietf.org id aa25880; 28 Feb 97 7:55 EST
Received: by relay.hq.tis.com; id HAA09254; Fri, 28 Feb 1997 07:51:31 -0500 (EST)
Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (3.2)
id xma009243; Fri, 28 Feb 97 07:51:23 -0500
Received: from [10.33.112.20] (flapdoodle.hq.tis.com [10.33.112.20]) by clipper.hq.tis.com (8.7.5/8.7.3) with ESMTP id HAA12983; Fri, 28 Feb 1997 07:49:00 -0500 (EST)
X-Sender: lewis at pop.hq.tis.com
Message-Id: <v03007801af3c7b9cb9cc at [10.33.112.20]>
In-Reply-To: <Pine.SUN.3.91.970227153007.13158E-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Feb 1997 07:35:52 -0500
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
Sender:ietf-request at ietf.org
From: Edward Lewis <lewis at tis.com>
Subject: Forging subscriptions - was Re: Remove us from the mailing list
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 3:39 PM -0500 2/27/97, Donald E. Eastlake 3rd wrote:
>Forging people's names on subscriptions to mailing lists is becoming a daily
>occurance....
Just a thought, not to start a deep technical thread on the general list.
Without being able to authenicate the subscription requestor (at this
time), could a tape-and-glue fix be as simple as: when a request for
subscription is received, a confirmation is requested (i.e., in a mail
message to the subscribing address), and until a returned confirmation is
received, the subscription is not made? I've heard that this approach is
being used with at least one (non-IETF) mail list.
A forger would have to be in the path of the forged address to see the
confirmation message. To prevent predicatability of the confirmation a
somewhat random phrase could be used in the confirmation request and reply.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis Trusted Information Systems
Phone: 301-854-5794 Email: lewis at tis.com
Received: from ietf.org by ietf.org id aa29299; 28 Feb 97 8:33 EST
Received: from ietf.ietf.org by ietf.org id aa29163; 28 Feb 97 8:30 EST
To: ietf at ietf.org
Subject: Re: "REMOVE" function
Sender:ietf-request at ietf.org
From: Dale R Worley <worley at world.std.com>
Date: Fri, 28 Feb 1997 08:30:22 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9702280830.aa29163 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
In article <01BC24FF.24E21CF0 at localhost> jon at interact-net.com (Jon Davis)
writes:
I was stumped. I had no way of knowing how to remove myself.
Append "-request" to the name of the list and send a request for
removal from that list, per Internet standards of about twenty years'
duration.
(Yes, if you're only used to Microsoft products, you won't know that,
because Microsoft does everything differently. But you're in the Real
World now, and have to learn how the Real World does things.)
(This isn't a flame, it's just to point out that there are ways to
know what you needed to know.)
Dale
Received: from ietf.org by ietf.org id aa29620; 28 Feb 97 8:34 EST
Received: from ietf.ietf.org by ietf.org id aa29500; 28 Feb 97 8:33 EST
To: ietf at ietf.org
Subject: RFC 1990
Sender:ietf-request at ietf.org
From: Jon Davis <mackie at winternet.com>
Date: Fri, 28 Feb 1997 08:33:39 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9702280833.aa29500 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
Does anyone know where I can get an overview of RFC 1990 written in PLAIN
ENGLISH? I realize it's a technical outline and should only expect it to
be written in technical terms, but I was just wondering if anyone bothered
to try to rephrase the article in a clearer presentation than at
http://www.neda.com/rfc/rfc1990.txt
Thanks,
Jon Davis
Received: from ietf.org by ietf.org id aa04887; 28 Feb 97 9:23 EST
Received: from noc.msc.edu by ietf.org id aa04486; 28 Feb 97 9:19 EST
Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324))
id AA22968; Fri, 28 Feb 97 08:16:29 -0600
Sender:ietf-request at ietf.org
From: Tim Salo <salo at msc.edu>
Received: (salo at localhost) by uh.msc.edu (8.7.1/8.6.6) id IAA01066 for ietf at ietf.org; Fri, 28 Feb 1997 08:16:29 -0600 (CST)
Date: Fri, 28 Feb 1997 08:16:29 -0600 (CST)
Message-Id: <199702281416.IAA01066 at uh.msc.edu>
To: ietf at ietf.org
Subject: Re: "REMOVE" function
Source-Info: From (or Sender) name not authenticated.
> Subject: Re: "REMOVE" function
> From: Dale R Worley <worley at world.std.com>
> Date: Fri, 28 Feb 1997 08:30:22 -0500
>
> In article <01BC24FF.24E21CF0 at localhost> jon at interact-net.com (Jon Davis)
> writes:
> I was stumped. I had no way of knowing how to remove myself.
>
> Append "-request" to the name of the list and send a request for
> removal from that list, per Internet standards of about twenty years'
> duration.
Per one of a number of inconsistent "standards."
"The nice thing about standards is that there are so many
to choose from"
> (Yes, if you're only used to Microsoft products, you won't know that,
> because Microsoft does everything differently. But you're in the Real
> World now, and have to learn how the Real World does things.)
>
> (This isn't a flame, it's just to point out that there are ways to
> know what you needed to know.)
I suppose this _is_ intended as a flame, (of the lack of a _single_
standard in this area, not of you personally).
-tjs
Received: from ietf.org by ietf.org id aa10671; 28 Feb 97 10:31 EST
Received: from jekyll.piermont.com by ietf.org id aa10273; 28 Feb 97 10:26 EST
Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.5/8.6.12) with SMTP id KAA11728; Fri, 28 Feb 1997 10:22:18 -0500 (EST)
Message-Id: <199702281522.KAA11728 at jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol
To: Jon Davis <mackie at winternet.com>
cc: ietf at ietf.org
Subject: Re: RFC 1990
In-reply-to: Your message of "Fri, 28 Feb 1997 08:33:39 EST."
<9702280833.aa29500 at ietf.org>
Reply-To: perry at piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 28 Feb 1997 10:22:17 -0500
Sender:ietf-request at ietf.org
From: "Perry E. Metzger" <perry at piermont.com>
Source-Info: From (or Sender) name not authenticated.
Jon Davis writes:
> Does anyone know where I can get an overview of RFC 1990 written in PLAIN
> ENGLISH? I realize it's a technical outline and should only expect it to
> be written in technical terms, but I was just wondering if anyone bothered
> to try to rephrase the article in a clearer presentation than at
> http://www.neda.com/rfc/rfc1990.txt
It seems pretty reasonable to read to me. If you are having trouble
with it, maybe you should hire a consultant to help you doing your
implementation.
Perry
Received: from ietf.org by ietf.org id aa19960; 28 Feb 97 12:19 EST
Received: from edu.lahti.fi by ietf.org id aa19506; 28 Feb 97 12:13 EST
Received: (qmail 3585 invoked by uid 1067); 28 Feb 1997 17:14:13 -0000
Date: Fri, 28 Feb 1997 19:14:13 +0200 (EET)
Sender:ietf-request at ietf.org
From: Sampo Syreeni <decoy at nexus.edu.lahti.fi>
To: Edward Lewis <lewis at tis.com>
cc: "Donald E. Eastlake 3rd" <dee at cybercash.com>, ietf at ietf.org
Subject: Re: Forging subscriptions - was Re: Remove us from the mailing list
In-Reply-To: <v03007801af3c7b9cb9cc at [10.33.112.20]>
Message-ID: <Pine.LNX.3.95.970228191200.3456C-100000 at nexus.edu.lahti.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Fri, 28 Feb 1997, Edward Lewis wrote:
> >Forging people's names on subscriptions to mailing lists is becoming a daily
> >occurance....
>
> Without being able to authenicate the subscription requestor (at this
> time), could a tape-and-glue fix be as simple as: when a request for
> subscription is received, a confirmation is requested (i.e., in a mail
> message to the subscribing address), and until a returned confirmation is
> received, the subscription is not made?
A good idea. Only one problem needs to be fixed: the list should note
pending confirmations and refuse to send more of them even if more
subscriptions are received. Otherwise it would be easy to flood someone
with confirmations. Of course, the confirmations would have to time out...
Sampo Syreeni (Decoy/dAWN), student, <decoy at edu.lahti.fi>
Received: from ietf.org by ietf.org id aa22983; 28 Feb 97 12:55 EST
Received: from greatkhan.netmeg.net by ietf.org id aa22783; 28 Feb 97 12:51 EST
Received: by greatkhan.netmeg.net (Smail3.1.29.1 #1)
id m0w0WPk-0001V4C; Fri, 28 Feb 97 12:48 EST
Message-Id: <m0w0WPk-0001V4C at netmeg.net>
Date: Fri, 28 Feb 97 12:48 EST
Sender:ietf-request at ietf.org
From: Matt Magri <matt at netmeg.net>
To: ietf at ietf.org
Subject: Re: Remove us from the mailing list
In-Reply-To: <Pine.SUN.3.91.970227153007.13158E-100000 at cybercash.com>
Source-Info: From (or Sender) name not authenticated.
Donald E. Eastlake 3rd (dee at cybercash.com) wrote:
> Forging people's names on subscriptions to mailing lists is becoming a daily
> occurance. Spamming is becoming an hourly occurance.
[ ... ]
> much inconvenience) and no one should be added to the list unless at least an
> email loop confirmation occurs where you send mail asking for a confirmation
> of the subscritpion request and get back a postitive response from the
> subscription address.
There's no harm in setting something like that up. I've seen it used
on other lists so it shouldn't require reinventing the wheel.
Another thing to consider is poking the list software to add a line or
two to the bottom of each post:
====================== IETF Mailing List ==========================
To unsubscribe, e-mail ietf-request at ietf.org, subject "unsubscribe"
I hate to cruft up each post with extra administrivia, but it's
a pretty good fallback if someone gets on against their will.
By making "IETF Mailing List" and "ietf-request" variables, they
could use the same fix for all of their lists.
Matt
Received: from ietf.org by ietf.org id aa24799; 28 Feb 97 13:15 EST
Received: from greatkhan.netmeg.net by ietf.org id aa24479; 28 Feb 97 13:12 EST
Received: by greatkhan.netmeg.net (Smail3.1.29.1 #1)
id m0w0Wk8-0001V4C; Fri, 28 Feb 97 13:09 EST
Message-Id: <m0w0Wk8-0001V4C at netmeg.net>
Date: Fri, 28 Feb 97 13:09 EST
Sender:ietf-request at ietf.org
From: Matt Magri <matt at netmeg.net>
To: ietf at ietf.org
Subject: Re: "REMOVE" function
In-Reply-To: <199702281416.IAA01066 at uh.msc.edu>
Source-Info: From (or Sender) name not authenticated.
Tim Salo (salo at msc.edu) wrote:
> Dale R Worley (worley at world.std.com) wrote:
> > In article <01BC24FF.24E21CF0 at localhost> jon at interact-net.com (Jon Davis)
> > writes:
> > I was stumped. I had no way of knowing how to remove myself.
> >
> > Append "-request" to the name of the list and send a request for
> > removal from that list, per Internet standards of about twenty years'
> > duration.
>
> Per one of a number of inconsistent "standards."
>
> "The nice thing about standards is that there are so many
> to choose from"
Whatever. Lest it get lost in the noise, however, Dave was presenting
information which is very valuable to someone new to the net.
Inconsistent standards notwithstanding, it's *always* a good idea to
try the -request trick before actually posting to the list address.
Even if you don't get the command right you'll usually get something
back either telling what the commands are or how you can find out what
they are.
And, until you can get off a list, you should be able to filter the
unwanted mail out of your regular mailbox. Unix folks can check out the
Mail Filtering FAQ (it's available in a number of places, including our
mirror at http://www.netmeg.net/faq/internet/mail/filtering-faq/)...
I'm sure there must be similar software for Windows platforms, etc.
Matt
Received: from ietf.org by ietf.org id aa03364; 28 Feb 97 14:56 EST
Received: from icicle.winternet.com by ietf.org id aa02877; 28 Feb 97 14:49 EST
Received: (from adm at localhost) by icicle.winternet.com (8.7.5/8.7.5) id NAA22053 for <ietf at ietf.org>; Fri, 28 Feb 1997 13:46:36 -0600 (CST)
Posted-Date: Fri, 28 Feb 1997 13:46:36 -0600 (CST)
Received: from mackie.winternet.com(204.246.64.78) by icicle.winternet.com via smap (V2.0beta)
id xma022034; Fri, 28 Feb 97 13:46:27 -0600
Received: from www.interact-net.com by www.interact-net.com (NTMail 3.02.10) with ESMTP id da000107 for <ietf at ietf.org>; Fri, 28 Feb 1997 13:54:51 +0000
Received: by localhost with Microsoft Mail
id <01BC257E.F7109F60 at localhost>; Fri, 28 Feb 1997 13:54:50 -0600
Message-ID: <01BC257E.F7109F60 at localhost>
Sender:ietf-request at ietf.org
From: Jon Davis <jon at interact-net.com>
To: "ietf at ietf.org" <ietf at ietf.org>
Subject: Re: RFC 1990
Date: Fri, 28 Feb 1997 13:50:15 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Info: Evaluation version at www.interact-net.com
Source-Info: From (or Sender) name not authenticated.
By the way, I do stand corrected. RFC 1990 is well-written, and I apologize, I must not have taken a very good look at it.
Jon Davis
Received: from ietf.org by ietf.org id aa10964; 28 Feb 97 16:37 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa10550; 28 Feb 97 16:31 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id QAA28082; Fri, 28 Feb 1997 16:29:03 -0500 (EST)
Message-Id: <199702282129.QAA28082 at ig.cs.utk.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: Matt Magri <matt at netmeg.net>
cc: ietf at ietf.org, moore at cs.utk.edu
Subject: Re: Remove us from the mailing list
In-reply-to: Your message of "Fri, 28 Feb 1997 12:48:00 EST."
<m0w0WPk-0001V4C at netmeg.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 28 Feb 1997 16:29:03 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> Another thing to consider is poking the list software to add a line or
> two to the bottom of each post:
>
> ====================== IETF Mailing List ==========================
> To unsubscribe, e-mail ietf-request at ietf.org, subject "unsubscribe"
>
Appending something to a message is not a good idea, especially with
MIME mail...it amounts to corruption of the message.
For what it's worth, an informal group is working on a draft for
adding such information to the message header, in the form of mailto:
URLs. So if your UA recognizes embedded URLs, you can simply click on
the URL in the List-Unsubscribe header field to unsubscribe.
Presumably, more UAs will be taught about this feature if it's
standardized.
I'm trying to get them to request a BOF for the Memphis IETF.
Meanwhile, interested parties can subscribe to their list by clicking
on the following URL :) (assuming your UA supports not only URLs but
the newly-invented-but-not-yet-standardized extended mailto syntax)
mailto:list-header at arpp.carleton.ca?Subject=subscribe%20list-header
(Be forewarned: the list software they're using exhibits many of the
kinds of brain-damage I mentioned in my recent flame...note for
example the lack of a seperate -REQUEST address for requests...but
they say some of the problems are being fixed.)
-Keith
Received: from ietf.org by ietf.org id aa14345; 28 Feb 97 17:20 EST
Received: from apprentice.qualcomm.com by ietf.org id aa14201;
28 Feb 97 17:17 EST
Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id OAA01205; Fri, 28 Feb 1997 14:10:48 -0800 (PST)
X-Sender: jwn2 at mage.qualcomm.com
Message-Id: <v03101711af3cfaa80bb2 at [129.46.166.223]>
In-Reply-To: <Pine.SUN.3.91.970227180639.18109B at cybercash.com>
References: <v03101719af3bb8a2cc98 at [129.46.166.223]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Eudora [Macintosh version 3.1b23-3.97]
X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57
Date: Fri, 28 Feb 1997 14:01:22 -0800
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
Sender:ietf-request at ietf.org
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
Subject: Re: Remove us from the mailing list
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 6:14 PM -0500 2/27/97, Donald E. Eastlake 3rd wrote:
>On Thu, 27 Feb 1997, John W. Noerenberg wrote:
>
>> Date: Thu, 27 Feb 1997 14:28:09 -0800
>> From: John W. Noerenberg <jwn2 at qualcomm.com>
>>
>> At 3:39 PM -0500 2/27/97, Donald E. Eastlake 3rd wrote:
>> >
>> >The IETF list needs stronger control than it apparently has. For exampl=
e:
>> >at a minimum, only allow posting from people on the list (or on a separa=
te
>> >list you maintain so people who post from multiple addresses don't have =
too
>> >much inconvenience)
>>
>> Just because a list is public and membership unrestricted, why should tha=
t
>> imply posters cannot be anonymous?
>
>And where did I say they couldn't be? I just indicated that they should ha=
ve
>to go through an explicit email loop subscription cycle. As commonly
>happens, the abusers make life a bit more difficult for everyone else.
You didn't, and I know, Donald, that you would not seek to prevent
anonymity. But the consequence is unavoidable. Whatever identity is
chosen is recorded and becomes a property of the list -- and publicly
known. One could argue this identity is itself anonymous, but that is an
infinite regress. At best, one could say this identity is a pseudonym.
That's not the same as anonymity. If one is truly interested in
preserving one's anonymity, it is necessary to minimize the amount of
information about your identity that is revealed. Which means not giving
any identity. If our goal is to permit the free, unrestricted
dissemination of information, the requirement that information include some
identity is inconsistent. After all, an identity on the net is only some
set of information. You can't condition one set on a second and call the
first unrestricted.
>
>The existence of any lists on the general Internet with no restirction or
>confirmation on subscriptions is an open inviation to abuse, abuse which is
>occuring with increasing frequency. There are a variety of possible
>solutions or partial solutions to the email abuse problems we are
>seeing. Doing nothing is not one of these.
>
I quite agree.
best,
john noerenberg
jwn2 at qualcomm.com
--------------------------------------------------------------------
She discovered, as many a living being had discovered, that
rational decisions are far more easily made than carried out.
-- Orson Scott Card, Speaker for the Dead, 1986
--------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa16094; 28 Feb 97 17:40 EST
Received: from greatkhan.netmeg.net by ietf.org id aa15822; 28 Feb 97 17:36 EST
Received: by greatkhan.netmeg.net (Smail3.1.29.1 #1)
id m0w0ars-0001V4C; Fri, 28 Feb 97 17:33 EST
Message-Id: <m0w0ars-0001V4C at netmeg.net>
Date: Fri, 28 Feb 97 17:33 EST
Sender:ietf-request at ietf.org
From: Matt Magri <matt at netmeg.net>
To: ietf at ietf.org
Subject: Re: Remove us from the mailing list
In-Reply-To: <199702282129.QAA28082 at ig.cs.utk.edu>
Source-Info: From (or Sender) name not authenticated.
> > Another thing to consider is poking the list software to add a line or
> > two to the bottom of each post:
> >
> > ====================== IETF Mailing List ==========================
> > To unsubscribe, e-mail ietf-request at ietf.org, subject "unsubscribe"
>
> Appending something to a message is not a good idea, especially with
> MIME mail...it amounts to corruption of the message.
Hm, one might argue that someone posting MIME messages to a general
mailing list should expect to have problems. At any rate, the
insertion could be more sophisticated if there was some desire to
make it friendly to MIME attachments.
> For what it's worth, an informal group is working on a draft for
> adding such information to the message header, in the form of mailto:
> URLs. So if your UA recognizes embedded URLs, you can simply click on
> the URL in the List-Unsubscribe header field to unsubscribe.
Assuming they see it up in the headers when they're being bombarded
by a bunch of messages from some strange source. Still, it sounds like
a promising long-term solution.
Matt
Received: from ietf.org by ietf.org id aa16441; 28 Feb 97 17:44 EST
Received: from cnri by ietf.org id aa16371; 28 Feb 97 17:43 EST
Received: from inet2.tek.com by CNRI.Reston.VA.US id aa21493;
28 Feb 97 17:43 EST
Received: from icebox.vnd.tek.com by inet2.tek.com id <OAA13583 at inet2.tek.com>; Fri, 28 Feb 1997 14:41:19 -0800
Received: from icebox (localhost [127.0.0.1]) by icebox.vnd.tek.com (8.7.5/8.7.3) with ESMTP id OAA18735; Fri, 28 Feb 1997 14:48:33 -0800 (PST)
Message-Id: <199702282248.OAA18735 at icebox.vnd.tek.com>
To: "voccnet.com" <info at voccnet.com>
Cc: ietf at CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: "Ted Brunner 503.627.1317" <ted.brunner at tek.com>
Subject: remove
In-reply-to: Your message of Sun, 23 Feb 1997 05:08:17 -0800.
<199702231308.FAA10781 at georgia.sallynet.com>
Date: Fri, 28 Feb 1997 14:48:33 -0800
X-Orig-Sender: tedb at vnd.tek.com
Source-Info: From (or Sender) name not authenticated.
Ted Brunner Video and Networking Division
Tektronix
MS 50-490
ted.brunner at tek.com 14150 SW Karl Braun
503.627.1317 Beaverton OR 97005
Received: from ietf.org by ietf.org id aa17535; 28 Feb 97 17:55 EST
Received: from apprentice.qualcomm.com by ietf.org id aa17310;
28 Feb 97 17:53 EST
Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id OAA06442; Fri, 28 Feb 1997 14:49:37 -0800 (PST)
X-Sender: jwn2 at mage.qualcomm.com
Message-Id: <v0310170caf3cdd0a162b at [129.46.166.223]>
In-Reply-To: <199702272316.SAA24523 at also.media.org>
References: <9702272212.AA18017 at dcl.MIT.EDU> from "Theodore Y. Ts'o" at
Feb 27, 97 05:12:43 pm
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Eudora [Macintosh version 3.1b23-3.97]
X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57
Date: Fri, 28 Feb 1997 14:23:29 -0800
To: "Carl Malamud [IMS]" <carl at also.media.org>
Sender:ietf-request at ietf.org
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
Subject: Re: don't shoot the messenger
Cc: "Theodore Y. Ts'o" <tytso at mit.edu>, tkeller at unlinfo2.unl.edu,
bran at metacomm.com, schulzrinne at cs.columbia.edu, cnielsen at pbi.net,
ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 6:16 PM -0500 2/27/97, Carl Malamud [IMS] wrote:
>I agree with Ted ... there is a very strong and very real cost
>to spamming and mailbombing. When Santa was mailbombed at
>north.pole.org, we had three people working for a a week
>doing nothing but handle the situation. Likewise with spamming,
>a problem we had with tpc.int where people decided they
>had to fax 500 copies of a notice to 500 members of congress.
>
>IP level blocking was the only serious way to handle these
>problems. DNS blocks in sendmail or inetd were partially
>effective, but we found folks that spend their time damaging
>the world also tend not to have very effective network
>implementations (e.g., their dns tables are inevitably screwed
>up).
I'm not denying the costs. They are real, substantial, and the cause is
truly onerous.
But there can no doubt that appropriate use of the net is a social concern.
Those of us who have grown up on the net are used to an environment free
from the invasions of crass commercialism that characterizes the behavior
of spammers, and the social ineptitude of those who would disrupt the net's
operation in other ways. But there is no getting away from the fact that
the population of the net is becoming more like the population of the world
around us. Inasmuch as managing and directing human behavior is the
province of social institutions that range from villages to nations, then
social institutions must be the vehicle for sanctioning and disciplining
behavior that is inappropriate.
However, the net is a fundamentally different place. Never before has
there existed a means of sweeping aside the constraints that mark the
borders of every other human endeavor. The equivalent of villages or
nations do not exist on the net. The barriers on which we rely to define
interactions with other individuals and other communities do not exist.
Many others, including you, Carl, have written eloquently on how the net
has changed our perception of what human society can be and the
individual's place in it.
Yet here we are reporting techniques and debating the merits of methods
that do create barriers and do limit the dissemination of information,
information which many of us in this community find objectionable, no
doubt. But building walls! Putting up fences!!! Is this truly what we
seek? John Gilmore once said, "The Net treats censorship as damage and
routes around it."
The question about technical alternatives is not an idle one.
john noerenberg
jwn2 at qualcomm.com
--------------------------------------------------------------------
She discovered, as many a living being had discovered, that
rational decisions are far more easily made than carried out.
-- Orson Scott Card, Speaker for the Dead, 1986
--------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa17494; 28 Feb 97 17:55 EST
Received: from ietf.ietf.org by ietf.org id aa15878; 28 Feb 97 17:37 EST
To: IETF-Announce: ;
Subject: Hotel Reservation Update
Date: Fri, 28 Feb 1997 17:37:20 -0500
Sender:ietf-announce-request at ietf.org
From: Marcia Beaulieu <mbeaulie at ietf.org>
Message-ID: <9702281737.aa15878 at ietf.org>
1. If you are on the waiting list at the Peabody Hotel, the hotel
should call you when a room becomes available. Per the IETF contract,
you are entitled to the IETF group rate ($119 single; $129 double)
if a room is available at any time up to the start of the meeting.
2. As of this date, we have been informed that there are still rooms
available at the alternate hotel:
Holiday Inn Select
160 Union Avenue
Memphis, TN 38103
Phone: 901-525-5491 (you must call the hotel directly)
CI 1500; CO 1100
75 Rooms reserved until Monday, March 17, 1997
US$ 99.00/single; US$99.00/double
(please add 13.25% tax)
Specify: IETF or Internet Engineering Task Force
One night's room and tax to be submitted at time of
reservation. This deposit is refundable if the
reservation is canceled by 5:00pm CST on the day
prior to arrival. Deposit or guarantee may be in
the form of check or credit card.
3. We recognize that the primary hotel room block has filled
relatively quickly for the past several meetings. While we
typically must negotiate the block size up to two years in
advance, we are looking at ways to increase the size for the
meetings following Memphis.
Received: from ietf.org by ietf.org id aa06028; 28 Feb 97 20:38 EST
Received: from zephyr.isi.edu by ietf.org id aa05506; 28 Feb 97 20:31 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA00785>; Fri, 28 Feb 1997 17:28:18 -0800
Message-Id: <199703010128.AA00785 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2113 on Router Alert Option
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 28 Feb 97 17:28:18 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2113:
Title: IP Router Alert Option
Author: D. Katz
Date: February 1997
Mailbox: dkatz at cisco.com
Pages: 4
Characters: 7924
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2113.txt
This memo describes a new IP Option type that alerts transit routers
to more closely examine the contents of an IP packet. This is useful
for, but not limited to, new protocols that are addressed to a
destination but require relatively complex processing in routers along
the path.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--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: <970228172439.RFC at ISI.EDU>
SEND /rfc/rfc2113.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2113.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970228172439.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13364; 28 Feb 97 22:01 EST
Received: from shell1.aimnet.com by ietf.org id aa12858; 28 Feb 97 21:56 EST
Received: from localhost (dwm at localhost) by shell1.aimnet.com (8.8.5/SHELL) with SMTP id SAA24121; Fri, 28 Feb 1997 18:54:01 -0800 (PST)
Date: Fri, 28 Feb 1997 18:54:01 -0800 (PST)
Sender:ietf-request at ietf.org
From: "David W. Morris" <dwm at xpasc.com>
X-Sender: dwm at shell1.aimnet.com
To: Matt Magri <matt at netmeg.net>
cc: ietf at ietf.org
Subject: Re: Remove us from the mailing list
In-Reply-To: <m0w0ars-0001V4C at netmeg.net>
Message-ID: <Pine.SOL.3.95.970228185222.23818A-100000 at shell1.aimnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Fri, 28 Feb 1997, Matt Magri wrote:
> Assuming they see it up in the headers when they're being bombarded
> by a bunch of messages from some strange source. Still, it sounds like
> a promising long-term solution.
And assuming that their UA even shows the header. The decent UAs I've
seen don't by default blast that confusing junk on the screen.
Dave Morris
Received: from ietf.org by ietf.org id aa19297; 2 Mar 97 14:05 EST
Received: from Ostrogoth.gv-itf.unisource.nl by ietf.org id aa12978;
2 Mar 97 12:50 EST
Received: from ostrogoth.gv-itf.unisource.nl (ostrogoth.gv-itf.unisource.nl [194.151.95.241]) by ostrogoth.gv-itf.unisource.nl (8.7.6/8.7.3) with SMTP id OAA00818; Fri, 28 Feb 1997 14:55:18 +0100
Date: Fri, 28 Feb 1997 14:55:18 +0100 (MET)
Sender:ietf-request at ietf.org
From: Frank de Lange <frank at animalhouse.ml.org>
X-Orig-Sender: frank at ostrogoth.gv-itf.unisource.nl
Reply-To: Frank de Lange <frank at animalhouse.ml.org>
Subject: Re: Forging subscriptions - was Re: Remove us from the mailing list
To: Edward Lewis <lewis at tis.com>
cc: ietf at ietf.org
In-Reply-To: <v03007801af3c7b9cb9cc at [10.33.112.20]>
Message-ID: <ML-3.0.857138118.3978.frank at ostrogoth.gv-itf.unisource.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
> >Forging people's names on subscriptions to mailing lists is becoming a
> >daily occurance....
>
> Just a thought, not to start a deep technical thread on the general list.
>
> Without being able to authenicate the subscription requestor (at this
> time), could a tape-and-glue fix be as simple as: when a request for
> subscription is received, a confirmation is requested (i.e., in a mail
> message to the subscribing address), and until a returned confirmation is
> received, the subscription is not made? I've heard that this approach is
> being used with at least one (non-IETF) mail list.
>
> A forger would have to be in the path of the forged address to see the
> confirmation message. To prevent predicatability of the confirmation a
> somewhat random phrase could be used in the confirmation request and reply.
This does indeed work, a mechanism like this is in use at several sites (an
example of which is ml.org (Monolith), which uses a three-way handshake to
authenticate `subscribers' to their services (free DNS listings, but the same
principle is valid in any other service).
Frank
WWWWW ___________________________
## o o\ / Frank de Lange \
}# \| / +31-70-3712708 day \
##---# _/ +31-320-252965 night \
#### \frank.de.lange at inet.unisource.nl/
\ frank.de.lange at net.info.nl /
------------------------------
Received: from ietf.org by ietf.org id aa18841; 1 Mar 97 13:57 EST
Received: from box.nl by ietf.org id aa17732; 1 Mar 97 13:40 EST
Received: from cs-gj3-a4.hro.nl (cs-gj3-a4.hro.nl [145.24.129.136]) by box.nl (8.7.5/8.6.9) with SMTP id TAA23798 for <ietf at ietf.org>; Sat, 1 Mar 1997 19:37:29 +0100
Date: Sat, 1 Mar 1997 19:37:29 +0100
Message-Id: <199703011837.TAA23798 at box.nl>
X-Sender: unit at box.nl (Unverified)
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: michael_roetto <mike at box.nl>
Subject: "New Ideas for a WWW standard"
Source-Info: From (or Sender) name not authenticated.
Since I posted my "New Ideas for a WWW standard" the response has been
strong, and the argument vigorous. This being said, I'd like to make my
position more clear on certain issues raised in the argument, and also lay
out more clearly my purpose in writing the document.
I plan to revise my proposal in the coming days, in light of the argument
and my own further research. If anyone would like to collaborate let me know.
The original document plus comments can be found at
http://www.box.nl/~unit/mike/prop.htm
sincerely,
Michael Roetto
Clarifying points:
Web content should not be 'programmed'; a programming language is not suitable.
My suggestion was not that HTML be replaced. The idea was that a more
structural/function-based 'shell' be available to those who desire it. Of
course there are already possibilities: Java, Active-X, CGI/Perl, etc. But
what we have now is a hodgepodge. From a designer/programmer's point of
view this is not optimal. The point was raised that most web content is
static, and therefore a 'programming' approach is unneccesary. I would
suggest that most web content is static *because* of the lack of adequate
language resources. An ideal language should be one that allows for a high
degree of compatibility between the different language/script components.
For the user, dynamic content will always be more interesting. People
re-visit sites with dynamic content. Also for the programmer/designer,
dynamic content is a preferable situation. Even with good tools, manually
updating static content is slow and error-prone. I can really forsee a time
when dynamic content is the norm for the Web.
Naturally, changing standards in midstream would be a disaster. Of course a
new standard will not prevent vendor-specific enhancements. No standard has
ever prevented that. But, in my opinion the so-called standards of the W3C
have suffered the influence of Netscape/MS. Considering the fact that the
Web has become such a grass-roots phenomenon, it might be interesting to see
what would happen if the front-line designer/programmers were given some
input in the standards-adoptions process.
::::::::::::::::::::::::::::::::::::::::::
: Internet Design Unit :
: http://www.box.nl/~unit/idu :
: :
: Personal Page: :
: http://www.box.nl/~unit/mike :
::::::::::::::::::::::::::::::::::::::::::
Received: from cnri by ietf.org id aa11265; 1 Mar 97 19:43 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13449;
1 Mar 97 19:43 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <WAA17174 at pad-thai.cam.ov.com>; Sat, 1 Mar 1997 22:59:24 GMT
Message-Id: <9703012259.AA20824 at MIT.EDU>
Date: 01 Mar 1997 17:35 EST
To: cat-ietf at mit.edu
From: Alex Brown <alex at nortel.ca>
Subject: Unsubscribe
Precedence: bulk
unsubscribe cat-ietf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Desktop Systems Integration, Global Enterprise Services |
| Nortel Technology, Ottawa, Ontario, Canada |
| Email: alex at bnr.ca Phone (613) 763-3731 Fax: (613) 763-3283 |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Received: from ietf.org by ietf.org id aa10164; 2 Mar 97 12:26 EST
Received: from edu.lahti.fi by ietf.org id aa03281; 2 Mar 97 11:06 EST
Received: (qmail 11810 invoked by uid 1067); 2 Mar 1997 16:07:38 -0000
Date: Sun, 2 Mar 1997 18:07:38 +0200 (EET)
Sender:ietf-request at ietf.org
From: Sampo Syreeni <decoy at nexus.edu.lahti.fi>
To: "John W. Noerenberg" <jwn2 at qualcomm.com>
cc: IETF list <ietf at ietf.org>
Subject: Re: don't shoot the messenger
In-Reply-To: <v0310170caf3cdd0a162b at [129.46.166.223]>
Message-ID: <Pine.LNX.3.95.970302180037.11788A-100000 at nexus.edu.lahti.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Fri, 28 Feb 1997, John W. Noerenberg wrote:
> Those of us who have grown up on the net are used to an environment free
> from the invasions of crass commercialism that characterizes the behavior
> of spammers, and the social ineptitude of those who would disrupt the net's
> operation in other ways. But there is no getting away from the fact that
> the population of the net is becoming more like the population of the world
> around us.
And this is exactly why the principle of absolute freedom of speech
doesn't work anymore. Anarchy works as long as all the participants have
some minimum amount of respect for each other. It is seen in the society
that certain regulation is necessary for keeping the minority that doesn't
respect the society's rules in order. Traditionally this minority has kept
itself outside the Net community. As this is changing, there is a need to
change the rules on which the Net functions.
> The barriers on which we rely to define
> interactions with other individuals and other communities do not exist.
Do you define spamming as interaction? It's just as interactive as
slamming strangers in the face when you see them on the street.
But this is already way off the topic of this list.
Sampo Syreeni (Decoy/dAWN), student, <decoy at edu.lahti.fi>
Received: from ietf.org by ietf.org id aa19011; 2 Mar 97 21:21 EST
Received: from tomobiki-cho.cac.washington.edu by ietf.org id aa14894;
2 Mar 97 20:01 EST
Received: from Ikkoku-Kan.Panda.COM (john at UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id QAA09695; Sun, 2 Mar 1997 16:58:13 -0800 (PST)
Received: from localhost (jms at localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id QAA17662; Sun, 2 Mar 1997 16:58:10 -0800 (PST)
Date: Sun, 2 Mar 1997 16:12:59 -0800 (PST)
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: don't shoot the messenger
To: Sampo Syreeni <decoy at edu.lahti.fi>
cc: IETF list <ietf at ietf.org>
In-Reply-To: <Pine.LNX.3.95.970302180037.11788A-100000 at nexus.edu.lahti.fi>
Message-ID: <MailManager.857347979.17009.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, 2 Mar 1997 18:07:38 +0200 (EET), Sampo Syreeni wrote:
> And this is exactly why the principle of absolute freedom of speech
> doesn't work anymore. Anarchy works as long as all the participants have
> some minimum amount of respect for each other. It is seen in the society
> that certain regulation is necessary for keeping the minority that doesn't
> respect the society's rules in order. Traditionally this minority has kept
> itself outside the Net community. As this is changing, there is a need to
> change the rules on which the Net functions.
I believe that the appropriate term is "the tragedy of the commons".
The underlying problem is the contemporary fashion of "in your face" exercise
of freedom; the most egregious examples of which (alas) are found in the USA.
"In your face" is the flamboyant and unnecessary exercise of a "freedom" in a
way calculated to cause maximum offense; a refusal to recognize the freedom of
others *from* the exercise of that freedom.
I do not, however, believe that regulation will help. The only thing that
will help is the replacement of the current "receiver pays" model of email
with a "sender pays" model. I have some neat ideas about how to accomplish
this in Internet email, and hope to come up with an Internet Draft later this
year.
Received: from ietf.org by ietf.org id aa04893; 3 Mar 97 0:03 EST
Received: from net1.unety.net by ietf.org id aa25017; 2 Mar 97 22:30 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by net1.unety.net (8.7.3/8.7.3) with SMTP id UAA29582; Mon, 3 Mar 1997 20:56:53 -0600 (CST)
Received: by webster.unety.net with Microsoft Mail
id <01BC274F.ECBDE9A0 at webster.unety.net>; Sun, 2 Mar 1997 21:23:08 -0600
Message-ID: <01BC274F.ECBDE9A0 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: Sampo Syreeni <decoy at edu.lahti.fi>, 'Mark Crispin' <MRC at panda.com>
Cc: IETF list <ietf at ietf.org>
Subject: RE: don't shoot the messenger
Date: Sun, 2 Mar 1997 21:23:07 -0600
Encoding: 43 TEXT
Source-Info: From (or Sender) name not authenticated.
On Sunday, March 02, 1997 10:12 AM, Mark Crispin[SMTP:MRC at panda.com] wrote:
@ On Sun, 2 Mar 1997 18:07:38 +0200 (EET), Sampo Syreeni wrote:
@ > And this is exactly why the principle of absolute freedom of speech
@ > doesn't work anymore. Anarchy works as long as all the participants have
@ > some minimum amount of respect for each other. It is seen in the society
@ > that certain regulation is necessary for keeping the minority that doesn't
@ > respect the society's rules in order. Traditionally this minority has kept
@ > itself outside the Net community. As this is changing, there is a need to
@ > change the rules on which the Net functions.
@
@ I believe that the appropriate term is "the tragedy of the commons".
@
@ The underlying problem is the contemporary fashion of "in your face" exercise
@ of freedom; the most egregious examples of which (alas) are found in the USA.
@ "In your face" is the flamboyant and unnecessary exercise of a "freedom" in a
@ way calculated to cause maximum offense; a refusal to recognize the freedom of
@ others *from* the exercise of that freedom.
@
@ I do not, however, believe that regulation will help. The only thing that
@ will help is the replacement of the current "receiver pays" model of email
@ with a "sender pays" model. I have some neat ideas about how to accomplish
@ this in Internet email, and hope to come up with an Internet Draft later this
@ year.
@
In my opinion, once the Internet moves to a model
based on "platforms" instead of "protocols" based
on object technology and agents many of these
problems will go away.
With standard service reference models and
more emphasis on computers doing the work
vs. people, life for people will improve...
..of course, the life (or life span) for computers will diminish...
--
Jim Fleming
Unir Corporation
e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)
Received: from cnri by ietf.org id aa08235; 3 Mar 97 0:48 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa01579;
3 Mar 97 0:48 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <DAA12362 at pad-thai.cam.ov.com>; Mon, 3 Mar 1997 03:59:39 GMT
X-Organisation: Indian Institute of Technology, New Delhi.
Date: Mon, 3 Mar 1997 09:27:08 +0530 (IST)
From: Alok Srivastava <alok at henna.iitd.ernet.in>
Subject: unsubscribe
To: cat-ietf at mit.edu
Message-Id: <Pine.3.07.9703030908.A24651-5100000 at henna>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk
unsubscribe cat-ietf
Received: from ietf.org by ietf.org id aa08574; 3 Mar 97 1:03 EST
Received: from dot.netrex.net by ietf.org id aa04134; 2 Mar 97 23:43 EST
Received: from host226 (usr15-dialup34.mix2.Boston.mci.net [166.55.70.162]) by dot.netrex.net (8.8.5/8.7.3) with SMTP id XAA00168; Sun, 2 Mar 1997 23:39:44 -0500 (EST)
Message-Id: <3.0.1.32.19970302194915.00a238c0 at dilbert.is.chrysler.com>
Reply-To: rgm3 at chrysler.com
X-Sender: rgm3 at dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 02 Mar 1997 19:49:15 -0500
To: Matt Magri <matt at netmeg.net>, ietf at ietf.org
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: Remove us from the mailing list
In-Reply-To: <m0w0ars-0001V4C at netmeg.net>
References: <199702282129.QAA28082 at ig.cs.utk.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
At 05:33 PM 2/28/97 EST, Matt Magri wrote:
>
>Hm, one might argue that someone posting MIME messages to a general
>mailing list should expect to have problems. At any rate, the
>insertion could be more sophisticated if there was some desire to
>make it friendly to MIME attachments.
What about digitally signed MIME? Multipart-signed might actually happen
some day....
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from cnri by ietf.org id aa18387; 3 Mar 97 3:49 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa03569;
3 Mar 97 3:49 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <HAA18408 at pad-thai.cam.ov.com>; Mon, 3 Mar 1997 07:37:02 GMT
X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
Mon, 3 Mar 1997 08:36:41 +0100
X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
Mon, 3 Mar 1997 08:36:41 +0100
X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Mon, 3 Mar 1997 08:36:39 +0100
X400-Received: by /PRMD=CCETT/ADMD=ATLAS/C=FR/; Relayed;
Mon, 3 Mar 1997 08:34:02 +0100
Date: Mon, 3 Mar 1997 08:34:02 +0100
X400-Originator: rpoulet at ccett.fr
X400-Recipients: non-disclosure:;
X400-Mts-Identifier: [/PRMD=CCETT/ADMD=ATLAS/C=FR/;857374347 at ccett.fr]
X400-Content-Type: P2-1984 (2)
Content-Identifier: unsubscribe
Alternate-Recipient: Allowed
From: R?mi POULET <rpoulet at ccett.fr>
Message-Id: <01BC27AD.A5B131D0 at pcpoulet.ccett.fr>
To: "cat-ietf at mit.edu" <cat-ietf at mit.edu>
Subject: unsubscribe
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Precedence: bulk
unsubscribe
Remi POULET
FT-CNET/DSM/AMI/TCA
3, rue du Clos-Courtel
BP 58
35 512 CESSON SEVIGNE Cedex
FRANCE
Tel : (33) 2-99-12-48-78
fax :(33) 2-99-12-40-98
Received: from ietf.org by ietf.org id aa06776; 3 Mar 97 10:03 EST
Received: from ietf.ietf.org by ietf.org id aa03708; 3 Mar 97 9:23 EST
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-myers-auth-sasl-08.txt
Date: Mon, 03 Mar 1997 09:23:54 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703030923.aa03708 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Simple Authentication and Security Layer (SASL)
Author(s) : J. Myers
Filename : draft-myers-auth-sasl-08.txt
Pages : 14
Date : 02/27/1997
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-08.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-myers-auth-sasl-08.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-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.
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: <19970227100115.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-myers-auth-sasl-08.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-myers-auth-sasl-08.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970227100115.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06759; 3 Mar 97 10:03 EST
Received: from ietf.ietf.org by ietf.org id aa03787; 3 Mar 97 9:24 EST
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-civanlar-bmpeg-01.txt
Date: Mon, 03 Mar 1997 09:24:15 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703030924.aa03787 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : RTP Payload Format for Bundled MPEG
Author(s) : R. Civanlar, G. Cash, B. Haskell
Filename : draft-civanlar-bmpeg-01.txt
Pages : 6
Date : 02/27/1997
This document describes a payload type for bundled, MPEG-2 encoded video
and audio data to be used with RTP, version 2. Bundling has some advantages
for this payload type particularly when it is used for video-on-demand
applications. This payload type is to be used when its advantages are
important enough to sacrifice the modularity of having separate audio and
video streams.
A technique to improve packet loss resilience based on "out-of-band"
transmission of MPEG-2 specific, vital information is described also.
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-civanlar-bmpeg-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-civanlar-bmpeg-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-civanlar-bmpeg-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.
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: <19970227140419.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-civanlar-bmpeg-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-civanlar-bmpeg-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970227140419.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06769; 3 Mar 97 10:03 EST
Received: from ietf.ietf.org by ietf.org id aa03752; 3 Mar 97 9:24 EST
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-myers-sasl-pop3-01.txt
Date: Mon, 03 Mar 1997 09:24:07 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703030924.aa03752 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : POP3 AUTHentication command
Author(s) : J. Myers
Filename : draft-myers-sasl-pop3-01.txt
Pages : 6
Date : 02/27/1997
This document describes the optional AUTH command, for indicating an
authentication mechanism to the server, performing an authentication
protocol exchange, and optionally negotiating a security layer for
subsequent protocol interactions. This extension is a profile of the
Simple Authentication and Session Layer [SASL].
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-sasl-pop3-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-myers-sasl-pop3-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-sasl-pop3-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.
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: <19970227100739.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-myers-sasl-pop3-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-myers-sasl-pop3-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970227100739.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06730; 3 Mar 97 10:03 EST
Received: from ietf.ietf.org by ietf.org id aa03781; 3 Mar 97 9:24 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-nai-01.txt
Date: Mon, 03 Mar 1997 09:24:13 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703030924.aa03781 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 Roaming Operations Working
Group of the IETF.
Title : The Network Access Identifier
Author(s) : B. Aboba
Filename : draft-ietf-roamops-nai-01.txt
Pages : 5
Date : 02/27/1997
This document describes issues relating to user identification in provision
of "roaming capability" for dialup Internet users. "Roaming capability"
may be loosely defined as the ability to use any one of multiple Internet
service providers (ISPs), while maintaining a formal, customer-vendor
relationship with only one. Examples of cases where roaming capability
might be required include ISP "confederations" and ISP-provided corporate
network access support.
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-roamops-nai-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-nai-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-roamops-nai-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.
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: <19970227140016.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-nai-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-nai-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970227140016.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08496; 3 Mar 97 10:05 EST
Received: from ietf.ietf.org by ietf.org id aa03724; 3 Mar 97 9:24 EST
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-myers-auth-sasl-08.txt
Date: Mon, 03 Mar 1997 09:24:01 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703030924.aa03724 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Simple Authentication and Security Layer (SASL)
Author(s) : J. Myers
Filename : draft-myers-auth-sasl-08.txt
Pages : 14
Date : 02/27/1997
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-08.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-myers-auth-sasl-08.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-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.
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: <19970227100115.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-myers-auth-sasl-08.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-myers-auth-sasl-08.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970227100115.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11690; 3 Mar 97 10:52 EST
Received: from auntie.bbcnc.org.uk by ietf.org id aa11203; 3 Mar 97 10:40 EST
Received: from auntie.bbcnc.org.uk by bbcnc.org.uk id aa02895;
3 Mar 97 15:37 GMT
Received: (naomi at localhost) by auntie.bbcnc.org.uk (8.6.12/8.6.12) id PAA02890; Mon, 3 Mar 1997 15:37:04 GMT
Date: Mon, 3 Mar 1997 15:37:04 +0000 (GMT)
Sender:ietf-request at ietf.org
From: Naomi Troski <naomi at tecc.co.uk>
X-Sender: naomi at auntie.bbcnc.org.uk
To: ietf <ietf at ietf.org>
Subject: Re: remove
In-Reply-To: <9702272125.AA16551 at smtpnotes.pictel.com>
Message-ID: <Pine.SUN.3.91.970303153634.1705L-100000 at auntie.bbcnc.org.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
remove
unsubscribe
take me off this list
Received: from ietf.org by ietf.org id aa15274; 3 Mar 97 11:26 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa14468; 3 Mar 97 11:21 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id LAA24104
for <ietf at ietf.org>; Mon, 3 Mar 1997 11:18:29 -0500
Message-Id: <199703031618.LAA24104 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: ietf at ietf.org
Subject: Re: Remove us from the mailing list
In-Reply-To: Your message of "Sun, 02 Mar 1997 19:49:15 EST."
<3.0.1.32.19970302194915.00a238c0 at dilbert.is.chrysler.com>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <199702282129.QAA28082 at ig.cs.utk.edu>
<3.0.1.32.19970302194915.00a238c0 at dilbert.is.chrysler.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-1007198018P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Mon, 03 Mar 1997 11:18:26 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-1007198018P
Content-Type: text/plain; charset=us-ascii
On Sun, 02 Mar 1997 19:49:15 EST, you said:
> What about digitally signed MIME? Multipart-signed might actually happen
> some day....
Might happen some day? ;)
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_-1007198018P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMxr5z9QBOOoptg9JAQGJxgP/Si231O4yaRDXiwrgspdbODPk9yZbiR6N
Y3TUf96lU0Y3CLBqCUaVQFaRcDplf4arclT5Nu97m0Df1xnpefbzUzA4vYy6mKiY
ybQyzoOMgtin1MDpDzut8+arZI2ZkBIcBiRVqD+sq1suddPNC8dzkqR4R4PZCoSf
2Ew1a0lspy4=
=OpRz
-----END PGP MESSAGE-----
--==_Exmh_-1007198018P--
Received: from ietf.org by ietf.org id aa17009; 3 Mar 97 11:53 EST
Received: from fnal.fnal.gov by ietf.org id aa16404; 3 Mar 97 11:47 EST
Received: from gungnir.fnal.gov ("port 35308"@gungnir.fnal.gov)
by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IG2A3XADWG0002TP at FNAL.FNAL.GOV> for
ietf at ietf.org; Mon, 03 Mar 1997 10:45:15 -0600
Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4)
id KAA27447; Mon, 03 Mar 1997 10:45:15 -0600
Date: Mon, 03 Mar 1997 10:45:14 -0600
Sender:ietf-request at ietf.org
From: Matt Crawford <crawdad at fnal.gov>
Subject: Re: don't shoot the messenger
In-reply-to: "26 Feb 1997 09:04:01 EST." <"331442D1.10E1"@cs.columbia.edu>
X-Orig-Sender: crawdad at gungnir.fnal.gov
To: ietf at ietf.org
Message-id: <199703031645.KAA27447 at gungnir.fnal.gov>
Content-transfer-encoding: 7BIT
X-Face:
/RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$! at A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{<k&QF?d6L7o&zLqb%kXn!!]ykXMKtTiy9#20]$EKP/^Z$T]'P6,
8L#r&mH4PB<ljN,_.=iCpv#N:HIcy5t7{HV:<=g=V?^;-d,J*xkq0r
Source-Info: From (or Sender) name not authenticated.
> I'd say: get all the spammers to sign up with one spam-only provider,
> find out what IP range they got and add a capability to sendmail to
> block that range. Unlike, say, netcom, you don't have to worry about
> blocking the mail of innocent bystanders.
I like my own plan even better: Put a wrapper around sendmail such
that if the connection is from the bad guys, you accept it with a
1-byte receive window and only issue a read() about once a minute.
And you always respond to the final "." with a transient failure
code.
_________________________________________________________
Matt Crawford crawdad at fnal.gov Fermilab
PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A
Received: from ietf.org by ietf.org id aa20279; 3 Mar 97 12:36 EST
Received: from greatkhan.netmeg.net by ietf.org id aa20057; 3 Mar 97 12:35 EST
Received: by greatkhan.netmeg.net (Smail3.1.29.1 #1)
id m0w1bay-0001UWC; Mon, 3 Mar 97 12:32 EST
Message-Id: <m0w1bay-0001UWC at netmeg.net>
Date: Mon, 3 Mar 97 12:32 EST
Sender:ietf-request at ietf.org
From: Matt Magri <matt at netmeg.net>
To: ietf at ietf.org
Subject: Re: Remove us from the mailing list
In-Reply-To: <3.0.1.32.19970302194915.00a238c0 at dilbert.is.chrysler.com>
Source-Info: From (or Sender) name not authenticated.
Robert Moskowitz <rgm3 at chrysler.com> wrote:
> Matt Magri wrote:
> >mailing list should expect to have problems. At any rate, the
> >insertion could be more sophisticated if there was some desire to
> >make it friendly to MIME attachments.
>
> What about digitally signed MIME? Multipart-signed might actually happen
> some day....
The problem is that innocent folks are getting attacked _today_. While
I have some sympathy with the idea of not getting in the way of
something that "might actually happen some day", I think it's pretty
obvious that any band-aid added to help the folks who need it today
can be removed when a better solution comes along. As far as the
band-aids that have been proposed so far in this thread go, I haven't
seen anything which isn't already happily in use on other mailing lists
I'm subscribed to. By all means, come up with the best long-term
solution possible but, in the meantime, let's not forget the folks that
need some kind of solution now. As long as the short-term solution
works in the current context *and* doesn't preclude the long-term
solution, then there's little harm to it. As I said, when it comes to a
workable short-term solution, you need look no farther than what's
already being used on other mailing lists.
Matt
Received: from ietf.org by ietf.org id aa20280; 3 Mar 97 12:36 EST
Received: from greatkhan.netmeg.net by ietf.org id aa20071; 3 Mar 97 12:35 EST
Received: by greatkhan.netmeg.net (Smail3.1.29.1 #1)
id m0w1bb6-0001UbC; Mon, 3 Mar 97 12:32 EST
Message-Id: <m0w1bb6-0001UbC at netmeg.net>
Date: Mon, 3 Mar 97 12:32 EST
Sender:ietf-request at ietf.org
From: Matt Magri <matt at netmeg.net>
To: ietf at ietf.org
Subject: Re: don't shoot the messenger
In-Reply-To: <MailManager.857347979.17009.mrc at Ikkoku-Kan.Panda.COM>
Source-Info: From (or Sender) name not authenticated.
Mark Crispin <MRC at panda.com> wrote:
>On Sun, 2 Mar 1997 18:07:38 +0200 (EET), Sampo Syreeni wrote:
>> And this is exactly why the principle of absolute freedom of speech
>> doesn't work anymore. Anarchy works as long as all the participants have
>> some minimum amount of respect for each other. It is seen in the society
>> that certain regulation is necessary for keeping the minority that doesn't
>> respect the society's rules in order. [ ... ]
If you mean regulation in the gov't sense I couldn't disagree more. If
you mean regulation in the net.sense, it's already happening, as it
has for the net's whole existence. It uses the same mechanism that it
always has: "If you don't cooperate I, at least, won't talk to you." This
method was certainly in use as early as ten years ago, which was about
as far back as I go on the net. Back then the concern was largely with
protocols, but the principle is the same.
>> [ ... ] Traditionally this minority has kept
>> itself outside the Net community. As this is changing, there is a need to
>> change the rules on which the Net functions.
Changes have been made all along to deal with changes in net traffic.
This not only includes technical changes to routers and connection
capacities, it also includes adding threading and killfiles to
newsreaders, hardening your server against SYN attacks, and, yes, IP
blocking of rogue sites. At the same time, it also includes educating
advertisers on net.friendly ways of getting their message out.
>I believe that the appropriate term is "the tragedy of the commons".
I was under the impression that that referred to the overuse of
resources which are not owned, resulting in a situation where the
future value of the resource is not worth more to the user than the
current value.
The difference here is that each piece of the net is owned. The owners
of each of these thousands and thousands of pieces have always been
expected to decide how their piece will interact with the rest of the
net. In the past the net was subject to an AUP which restricted
commercial traffic. When ownership changed, that was no longer a
net-wide policy, but one which is currently relegated to a few specific
parts of the net, owned by people who choose to have such a policy.
Each of the other parts of the net have policies, as well, and those
policies are implemented in software and administrative practices, just
as they have always been. As new types of traffic appear on the net,
policies are amended and implemented as needed. If enough of the
thousands and thousands of owners of the various pieces decide to
implement a particular policy, that policy will become, in effect,
net-wide. Currently, a number of owners are implementing policies to
help prevent spam from entering or leaving their pieces of the net. It
remains to be seen how many of the other owners will join them.
>I do not, however, believe that regulation will help. The only thing that
>will help is the replacement of the current "receiver pays" model of email
>with a "sender pays" model. I have some neat ideas about how to accomplish
>this in Internet email, and hope to come up with an Internet Draft later this
>year.
I'll be curious to see what you come up with. I'm not very happy with
the current scheme of simply blocking spam-friendly sites since it puts
such a burden on nonabusive users of the sites, as well. That *is* a
sender pays model, tho, since the price a provider pays to do interact
is to restrict, as much as is technically feasible, the release of
UCE's and other forms of spam from that site. And, I have to admit, if
there was no burden on the nonabusive users of that site, there'd also
be no incentive for the owners of that site to change their policy.
Anyway, if you can come up with a system that increases the cost of
wrong use without placing a bigger burden on right use then more power
to you. We could use some more neat ideas.
Of course, the new cyberpromo site which set off this thread is not a
provider in the traditional sense... it's _devoted_ to bulk UCE. IMHO,
blocking a site like that is a no-brainer.
Matt
Received: from ietf.org by ietf.org id aa22044; 3 Mar 97 12:55 EST
Received: from spinoza.terena.nl by ietf.org id aa21750; 3 Mar 97 12:50 EST
Received: (from root at localhost) by spinoza.terena.nl (8.7.6/8.7.3) id SAA25767 for nato-anw97-interest-list; Mon, 3 Mar 1997 18:46:03 +0100 (MET)
Date: Mon, 3 Mar 1997 18:46:03 +0100 (MET)
Message-Id: <199703031746.SAA25767 at spinoza.terena.nl>
Sender:ietf-request at ietf.org
From: John Martin <martin at terena.nl>
To: Recipients.suppressed at spinoza.terena.nl
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: NATO Advanced Networking Workshop - 5-9 May 1997
Reply-To: nato-anw97 at terena.nl
Source-Info: From (or Sender) name not authenticated.
Dear Colleague,
Please find attached the application form for this year's NATO Advanced
Networking Workshop to be held in Edinburgh, UK, 5-9 May 1997.
Note that applications should be sent to nato-anw97 at terena.nl and *not*
to me directly.
Please feel free to distribute this to appropriate fora.
Regards,
John Martin
*************************************************************************
* John Martin *
* Trans-European Research and Education Networking Association *
* http://www.terena.nl/ *
* *
* TERENA Tel : +31 20 639 1131 *
* Singel 466-468 Fax : +31 20 639 3289 *
* NL-1017 AW Amsterdam UK : +44 141 339 9239 *
*************************************************************************
--
Application for NATO Advanced Networking Workshop - Migrating
Towards a High Speed Networking Service
5-9th May 1997
Introduction
------------
Adjacent to the TERENA Joint European Networking Conference in
Edinburgh in May 1997, a NATO Advanced Networking Workshop has
been organised with the theme: "Migrating Towards a High Speed
Networking Service". It is aimed at those who are currently
running national network services but who will, in the near
future, be moving to new technologies to provide new
applications, higher bandwidth and a more reliable service. The
workshop will be practical and technology-oriented but will also
provide some experience of network management and an exploration
of the application-level issues which arise with the newer
technology.
The event will be a single-track workshop with possibly a limited
number of parallel sessions. There will be classroom-style
lectures complemented by hands-on technical sessions where
appropriate and practicable.
For more details about the workshop, please see:
http://www.terena.nl/conf/nato-anw97/
------8<------8<------ cut here ------8<------8<------
Application
-----------
Please complete *all* sections as fully as possible and return
to:
nato-anw97 at terena.nl
Any additional information should be appended in plain ASCII
format.
A. Personal data:
FAMILY NAME:
First Name:
Sex[1]: Male / Female (please delete)
Employer:
Business Address:
Country[2]:
Business Telephone:
Business Fax:
E-mail:
B. Administration:
1. Accomodation: Please note that participants will be
required to share twin hotel rooms for the duration of the
workshop and conference. If you have any objections to this,
please let us know the reasons here:
2. Travel: Please indicate the approximate cost in US$ of
the cheapest method of travel from your place of residence
to Edinburgh, UK[3]:
C. Description of the candidate's role in National Networking
Activities:
1. Please give a brief summary of your educational
background:
2. Please supply a description of your current employer,
position, duties and responsibilities and how they relate to
current and future networking activities in your country:
3. Please outline details of work you have done with inter-
networking, and what you hope to achieve in the future with
the help of the knowledge gained at the workshop:
4. Upon your return from the workshop, how would you expect
to disseminate the knowledge you gain through attendance at
the workshop:
5. Please give details of any NATO Advanced Networking
Workshops you have participated in previously:
D. Please append any additional information in support of your
application here, in plain ascii text:
------8<------8<------ cut here ------8<------8<------
Notes:
[1] Please note that participants will be required to share twin
hotel rooms for the duration of the workshop and conference.
[2] Please note that only residents of NATO Co-operation Partner
(CP) countries are eligible to attend this workshop and receive
assistance from NATO. Eligible countries are: Albania, Armenia,
Azerbaijan, Belarus, Bulgaria, Czech Republic, Estonia, Georgia,
Hungary, Kazakhstan, Kyrgyzstan, Latvia, Lithuania, Moldova,
Poland, Romania, Russian Federation, Slovak Republic, Slovenia,
Tajikistan, the former Yugoslav Republic of Macedonia,
Turkmenistan, Ukraine, Uzbekistan
NATO countries: Belgium, Canada, Denmark, France, Germany,
Greece, Iceland, Italy, Luxembourg, Netherlands, Norway,
Portugal, Spain, Turkey, United Kingdom, United States.
[3] The period of stay will include a weekend and the dates of
travel should be so that you arrive on / before Sunday 4th May
and depart on / after Saturday 17th May. NB: Should you choose to
spend any additional time in Edinburgh before travelling home,
you must assume any costs incurred.
--end
Received: from ietf.org by ietf.org id aa23597; 3 Mar 97 13:14 EST
Received: from ietf.ietf.org by ietf.org id aa23446; 3 Mar 97 13:12 EST
To: ietf at ietf.org
Subject: MUX Modems (was Re: RFC 1990)
Sender:ietf-request at ietf.org
From: Jon Davis <mackie at winternet.com>
Date: Mon, 03 Mar 1997 13:12:54 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703031312.aa23446 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
I'm a student, not a company. What I'm doing is trying to speculate a
similar (but more basic and more broadly supported) "implementation" so to
speak of a single mux modem. Please see
http://www.interact-net.com/think/mux/MUXMODEM.html (and note that I'm 20
years old, somewhat unfamiliar with low-level networking technospeak, and I
had not read RFC 1990 at the time the mux modem model web page above was
produced). It's not an original concept, but it amazes me that modem
companies are not considering the support of multiplexing technology over
POTS connections. Forget the requirement of server-side compatibility
keeping it from happening, if US Robotics can successfully pull off x2,
they should be able to successfully pull off POTS multiplexing.
The mux modem model, therefore, would allow the average consumer to come
home with a single modem, plug it in, do basic software-based configuration
(plug-n-play), and connect to the Internet or BBS or a friend's computer at
twice the bandwidth. The idea here is obviously not multiplexing, which
has been around for decades--maybe as long as a century or more--but rather
*single POTS device* and its *marketability for the average consumer*.
I need professional comments on this (as I merely an internet
junkie/hobbiest). Should I study networking technology more and keep
working on this, or am I wasting my time? And why?
Thanks,
Jon
"Perry E. Metzger" <perry at piermont.com> wrote in article
<199702281522.KAA11728 at jekyll.piermont.com>...
>
> Jon Davis writes:
> > Does anyone know where I can get an overview of RFC 1990 written in
PLAIN
> > ENGLISH? I realize it's a technical outline and should only expect it
to
> > be written in technical terms, but I was just wondering if anyone
bothered
> > to try to rephrase the article in a clearer presentation than at
> > http://www.neda.com/rfc/rfc1990.txt
>
> It seems pretty reasonable to read to me. If you are having trouble
> with it, maybe you should hire a consultant to help you doing your
> implementation.
>
> Perry
>
Received: from ietf.org by ietf.org id aa23678; 3 Mar 97 13:15 EST
Received: from ietf.ietf.org by ietf.org id aa23547; 3 Mar 97 13:14 EST
To: ietf at ietf.org
Subject: Re: New Ideas for a WWW standard (fwd)
Sender:ietf-request at ietf.org
From: Jon Davis <mackie at winternet.com>
Date: Mon, 03 Mar 1997 13:14:15 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703031314.aa23547 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
I'm curious to see what Microsoft's plan with dynamic HTML is going to look
like before watching yet another "web standard" pop up.
Jeff Jones <jdjones at sprynet.com> wrote in article
<199702151439.GAA19860 at m3.sprynet.com>...
> > From MegaZone:
> >
> > I hardly think it is dying. The UNIX base is growing.
> As a share of the market in servers and workstations, the facts are
> otherwise.
>
>
> > >convinced, it will not happen. While a team of programmers can use
HTML
> > >3.2, CGI, Java, and CSS1 on their UNIX system for months to build a
web
> > >project, I or any good VB programmer can do the same project, with
> > >equivalent or better performance in just a few weeks. To the customer
> >
> > I completely disagree with this.
> I have no problem with you disagreeing. That is what an open forum is
> about. Unfortunately, I say this based on a past history of successfully
> doing this in the VB/Win32 world in competition with UNIX programmers and
> HTML/Java/CGI programmers. I doubt I am the only one capable of doing
> this.
>
> >
> > First, HTML and CSS1 are cake - anyone should be able to use them with
> ease.
> > And there are several good tools on the market - such as HoTMetaL PRO.
> Yes, there are. Especially the free ones or the shareware ones nobody is
> honest enough to pay for, like HoTMetaL. I use Frontpage in tandem with
> VB4. It is not the only solution, but it works for me, and I turn out my
> projects in less time that others with similar projects.
>
> >
> > Second, pick a language - let's say Perl - a skilled Perl programmer
can
> > create the same application just as fast as a silling VB programmer can
> > do it in VB. And with Perl 5 there are literally hundreds of modules
you
> > can plug together like legos - it greatly reduces the coding time. And
> any
> > full time webmaster is going to write their own Perl library to make
life
> > easier - then you just use your ready-made routines.
> People should use what they want. My argument was in support of a
> standard, like HTML has a published standard today. How about a
specified
> project, given to Perl & VB programmers to do, and a contest to judge the
> results based on quality and time to production? It would certainly
> generate some interest, given all the nasty-grams I get for even
mentioning
> VB to "REAL" programmers.
>
> >
> > Actually programming page content is a completely warped, completely
> terrible
> > idea no matter what you use. It adds completely pointless overhead to
> > the process that is not worth it. When you can mark up a file with
HTML
> > and Style Sheets, and MOST of the web is NOT dynamic content so this
> > covers it, it doesn't make sense to turn to a more programatic syntax.
> If you like HTML, Perl, FastCGI, then you must like some degree of
> overhead. Java is interpreted code, like VB4. Please keep in mind that
I
> am not recommending VB4 as a substitute for a standard. I am merely
> pointing out that the success of a future standard is measured by how
> broadly it is adopted inside and outside of the techie world. The
success
> of VB4, the wide audience for BASIC, and the methodology of how VB has
> incorporated other languages certainly provides a starting point for that
> standard.
>
> >
> > >looking at the life cycle cost, the VB approach always wins. One must
> look
> >
> > That is flat out incorrect. It wins SOME of the time, NOTHING wins all
> of
> > the time. VB doesn't even win most of the time.
> Then specify a scenario - perhaps in the contest above. Specify a real
> world system, with web server, database support, encryption, client side
> features, etc. Require a life cycle cost analysis in the contest. Then
> let's see. A lot of creative minds could tackle this with the religious
> fervor that seems to permeate the UNIX and NT faithful. My real world
> experience, competing against mini and mainframe systems, is that VB
wins.
> Everytime it is tried.
> >
> > >beyond the technology to the intended result and resources. That is
why
> I
> > >simply suggest that standardizing on MS's Basic syntax, or a
reasonable
> >
> > When you have a hammer, everything looks like a nail. You know VB, so
> > you want to standardize on that. I know other Windows programmers who
> would
> > say you're high and C++ is the way to go. My personal fave is Perl,
> followed
> > by C. Someone else will say we're all obviously clueless and Java is
the
> > standard to use.
> Actually, I have changed languages several times over the years to allow
me
> to produce the best product I can for my customers. I started with
machine
> code in the late 70's on Barber-Colman systems, then to Fortran IV and
77,
> then to xBase & Clipper in the DOS world, then to VB in the Windows
world.
> C (and C++) are the ideal, but impractical for development unless you
have
> a huge ROI that pays for it (as in major commercial applications or
writing
> multi-platform operating systems). Hardly a Johnny-one-note in
> programming. The same holds true for my network design. I started with
a
> slow serial net in the early 80s (Barber Colman), then on to Token Ring
and
> Ethernet, to FDDI, Fast Ethernet, and gigabit Ethernet. I went from
> applying repeaters on thinnet to hubs and routers, to switches. From 300
> baud dial up to ISDN, SMDS, and frame relay. I adopt the technology in
any
> field that best suits the short and long term needs.
> >
> > >Perhaps selling MS, Sun, and Netscape on CSS1 would be another good
> idea.
> >
> > As I said, at least MS and NS have already committed to it. MSIE 3.x
has
> > a decent level of support, and MSIE 4.0 and NS 4.0 will supposedly
> support
> > the entire spec. Sun/Java doesn't really enter into it, since applets
> > control their area on their own. Though CSS1 can be used to position
it,
> etc.
> I wholeheartedly agree.
>
> >
> > For the various needs:
> > HTML is for document structure, and some basic layout.
> >
> > CSS1 and following levels will provide increasing levels of fine
> > presentational control.
> >
> > Server Side - define an interface and let people code what they like,
> THAT
> > is the most efficient way. CGI is in need of an overhaul, FastCGI
looks
> > like an effective replacement.
> >
> > Client side - This is a weak spot. A real standardized scripting
> language
> > would be welcome. To be practical I think that should be JavaScript as
> that
> > is the one most widely used and more fully developed. If only MS would
> stop
> > diluting their efforts wit VBScript and JS - and NS would make it an
open
> > spec instead of screwing with it at whim.
> >
> > If anything needs to be worked on, it is the client side scripting.
> >
> > Structure is well in hand and the future is bright, same for
> presentation.
> > CGI and other server issues can be written in the most appropriate
> language
> > for the task and platform - as I strongly feel it should be.
> >
> > Things are really just starting to congeal with the feature war in the
> > browsers really calming down and MS and NS both publically stating that
> > they will abide by the W3C recomendatins on things like HTML and Style
> > Sheets.
> >
> > -MZ
> I agree with this, also. I appreciate how you argue intelligently, and
> avoid the ad hominums that others have made in reply. I learn something
> new from each of your postings.
>
> Jeff Jones
> Remote Monitoring System Services Manager
> UB Networks CSMC Atlanta
> 888-80UBNET
>
> "ALLOPINONS EXPRESSED ARE MY OWN AND NOT NECESSARILY THOSE OF UB
NETWORKS"
>
Received: from ietf.org by ietf.org id aa23732; 3 Mar 97 13:15 EST
Received: from ietf.ietf.org by ietf.org id aa23626; 3 Mar 97 13:14 EST
To: ietf at ietf.org
Subject: Re: Remove us from the mailing list
Sender:ietf-request at ietf.org
From: "Dale R. Worley" <worley at ariadne.com>
Date: Mon, 03 Mar 1997 13:14:56 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703031314.aa23626 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
In article <Pine.SOL.3.95.970228185222.23818A-100000 at shell1.aimnet.com>
dwm at xpasc.com ("David W. Morris") writes:
> Assuming they see it up in the headers when they're being bombarded
> by a bunch of messages from some strange source. Still, it sounds like
> a promising long-term solution.
And assuming that their UA even shows the header. The decent UAs I've
seen don't by default blast that confusing junk on the screen.
Although, of course, any decent UA will display the complete headers
upon request.
Dale
--
Dale R. Worley Ariadne Internet Services
Voice: +1 617-899-7949 Fax: +1 617-899-7946 E-mail: worley at ariadne.com
"Internet-based electronic commerce solutions to real business problems."
Received: from ietf.org by ietf.org id aa25926; 3 Mar 97 13:38 EST
Received: from zephyr.isi.edu by ietf.org id aa25429; 3 Mar 97 13:29 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA04576>; Mon, 3 Mar 1997 10:26:14 -0800
Message-Id: <199703031826.AA04576 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2114 on DCAP
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 03 Mar 97 10:26:14 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2114:
Title: Data Link Switching Client Access Protocol
Author: S. Chiang, J. Lee, H. Yasuda
Date: February 1997
Mailbox: schiang at cisco.com, jolee at cisco.com,
yasuda at eme068.cow.melco.co.jp
Pages: 22
Characters: 50872
Updates/Obsoletes: 2106
URL: ftp://ds.internic.net/rfc/rfc2114.txt
This memo describes the Data Link Switching Client Access Protocol
that is used between workstations and routers to transport SNA/
NetBIOS traffic over TCP sessions.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--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: <970303102031.RFC at ISI.EDU>
SEND /rfc/rfc2114.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2114.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970303102031.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29155; 3 Mar 97 14:20 EST
Received: from tomobiki-cho.cac.washington.edu by ietf.org id aa28974;
3 Mar 97 14:18 EST
Received: from Ikkoku-Kan.Panda.COM (senf at UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id LAA10626; Mon, 3 Mar 1997 11:15:37 -0800 (PST)
Received: from localhost (sdennis at localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id LAA20814; Mon, 3 Mar 1997 11:15:33 -0800 (PST)
Date: Mon, 3 Mar 1997 10:59:04 -0800 (PST)
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: don't shoot the messenger
To: Matt Magri <matt at netmeg.net>
cc: ietf at ietf.org
In-Reply-To: <m0w1bb6-0001UbC at netmeg.net>
Message-ID: <MailManager.857415544.17009.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, 3 Mar 97 12:32 EST, Matt Magri wrote:
> >> It is seen in the society
> >> that certain regulation is necessary for keeping the minority that
> >> doesn't respect the society's rules in order.
> If you mean regulation in the gov't sense I couldn't disagree more. If
> you mean regulation in the net.sense, it's already happening, as it
> has for the net's whole existence.
For most of the net's existance, it was "regulated in the gov't sense." By
the US Department of Defense, first under ARPA, later under DCA. Then under
the National Science Foundation. Such regulation ended only a few years ago.
> It uses the same mechanism that it
> always has: "If you don't cooperate I, at least, won't talk to you."
This is a relatively recent phenomenum. In the past, abuse complaints went to
DCA, who would call the offender on the carpet (as in "show cause why the
order to pull the plug on your net connection in 4 hours should be reversed").
> This
> method was certainly in use as early as ten years ago, which was about
> as far back as I go on the net.
The net has been around for over 25 years. Some of us go back that far. But
even as recently as 10 years ago, there was a thing called an AUP (Acceptable
Use Policy) in force.
Received: from ietf.org by ietf.org id aa02698; 3 Mar 97 15:05 EST
Received: from greatkhan.netmeg.net by ietf.org id aa02502; 3 Mar 97 15:03 EST
Received: by greatkhan.netmeg.net (Smail3.1.29.1 #1)
id m0w1duC-0001UWC; Mon, 3 Mar 97 15:00 EST
Message-Id: <m0w1duC-0001UWC at netmeg.net>
Date: Mon, 3 Mar 97 15:00 EST
Sender:ietf-request at ietf.org
From: Matt Magri <matt at netmeg.net>
To: ietf at ietf.org
Subject: Re: don't shoot the messenger
In-Reply-To: <MailManager.857415544.17009.mrc at Ikkoku-Kan.Panda.COM>
Source-Info: From (or Sender) name not authenticated.
Mark Crispin <MRC at Panda.COM> wrote:
>On Mon, 3 Mar 97 12:32 EST, Matt Magri wrote:
>> >> It is seen in the society
>> >> that certain regulation is necessary for keeping the minority that
>> >> doesn't respect the society's rules in order.
>>
>> If you mean regulation in the gov't sense I couldn't disagree more. If
>> you mean regulation in the net.sense, it's already happening, as it
>> has for the net's whole existence.
>
>For most of the net's existance, it was "regulated in the gov't sense." By
>the US Department of Defense, first under ARPA, later under DCA. Then under
>the National Science Foundation. Such regulation ended only a few years ago.
That is, of course, not what I was referring to as "regulated in the
gov't sense." We can rehash history about what the management actually
consisted of at that time, but that's only necessary if you harbor some
belief that regulation of the net today would bear any resemblence to
the historical version. I submit to you that it not only would not, it
could not.
>> It uses the same mechanism that it
>> always has: "If you don't cooperate I, at least, won't talk to you."
>
>This is a relatively recent phenomenum. In the past, abuse complaints went to
>DCA, who would call the offender on the carpet (as in "show cause why the
>order to pull the plug on your net connection in 4 hours should be reversed").
You're focusing too tightly on the recent phenomenon. As I said, the
issue then was not primarily "abuse", it was being broken. If my servers
hadn't spoken the protocols properly back then, what would have happened?
Or, to use a more recent, and less dire, example, if I created my own
comp.* group, would it have been propagated? The basic mechanism is to
avoid that which is broken and protect your site from any damage that
brokeness may cause, as much as is technically possible. You are correct
that, at the time, there always existed the ultimate penalty of having
a central authority pull the plug, but in practice that was not as
simple a process as you imply.
>> This
>> method was certainly in use as early as ten years ago, which was about
>> as far back as I go on the net.
>
>The net has been around for over 25 years. Some of us go back that far.
Sigh. Hence my caveat about the limit to my personal experience. I'm
sorry if you interpreted that as some sort of bragging. I would have
thought that it would have been taken as a gesture of respect for those
who actually do go back that far. At any rate, since I was giving
examples from within the last 10 years then I hope my meager experience
will prove sufficient.
> [ ... ] But
>even as recently as 10 years ago, there was a thing called an AUP (Acceptable
>Use Policy) in force.
As I mentioned in my last post. It's existence was, in fact, a key
point in the argument I was making that placing limits on the kind of
traffic an owner wants to accept is not groundbreaking. I'm sorry if
the reference wasn't clear enough.
Matt
Received: from ietf.org by ietf.org id aa04882; 3 Mar 97 15:31 EST
Received: from ietf.ietf.org by ietf.org id aa04427; 3 Mar 97 15:21 EST
To: IETF-Announce: ;
Subject: WG ACTION: Multiprotocol Label Switching (mpls)
Date: Mon, 03 Mar 1997 15:20:59 -0500
Sender:ietf-announce-request at ietf.org
From: Cynthia Clark <cclark at ietf.org>
Message-ID: <9703031521.aa04427 at ietf.org>
A new working group has been formed in the Routing Area
of the IETF. For additional information, contact the Area Directors
or the WG Chair.
Multiprotocol Label Switching (mpls)
------------------------------------
Chair(s):
Vijay Srinivasan <vijay at raleigh.ibm.com>
George Swallow <swallow at cisco.com>
Routing Area Director(s):
Joel Halpern <jhalpern at newbridge.com>
Area Advisor
Joel Halpern <jhalpern at newbridge.com>
Mailing lists:
General Discussion:mpls at external.cisco.com
To Subscribe: mpls-request at cisco.com
In Body: in body: subscribe
Archive: ftp://ftp.cisco.com/ftp/mpls
Description of Working Group:
Problem Statement:
Recently the use of label-swapping based forwarding ("label switching")
in conjunction with network layer routing has attracted much attention.
Several vendors have proposed techniques based on this paradigm. Among
the problems this paradigm is expected to address are the following:
1. Scalability of network layer routing
Using labels as a means to aggregate forwarding information, while
working in the presence of routing hierarchies.
2. Greater flexibility in delivering routing services
Using labels to identify particular traffic which are to receive
special services, e.g. QoS.
Using labels to provide forwarding along an explicit path different
from the one constructed by destination-based forwarding.
3. Increased performance
Using the label-swapping paradigm to optimize network performance.
4. Simplify integration of routers with cell switching based
technologies
a) making cell switches behave as peers to routers (thus reducing
the number of routing peers that a router has to maintain),
b) by making information about physical topology available to
Network Layer routing procedures, and
c) by employing common addressing, routing, and management
procedures.
High Level Requirements
1. The solution should be general with respect to data link
technologies. Specific optimizations for particular media will be
considered.
2. The solution must be compatible with existing internetwork
technologies and routing protocols.
3. The solution should be capable of operating independently of the
underlying routing protocol. It has been observed that
considerable optimizations can be achieved in some cases by small
enhancements of existing protocols. Such enhancements will be
considered in the case of IETF standard routing protocols, and if
appropriate, coordinated with the relevant working group.
4. The solution should support a wide range of forwarding
granularities associated with a given label, from a single
application flow to a group of topologically related destinations.
5. The solution should support operations, administration, and
maintenance facilities at least as extensive as those supported in
IP networks.
6. Routing protocols that could be used in conjuction with MPLS
could be based on distributed computation. As such, during routing
transients these protocols may construct forwarding paths that
contain loops. The protocols defined by MPLS must provide protocol
mechanism(s) to either prevent the formation of loops and/or
contain the amount of (networking) resources that could be consumed
due to the presence of such loops.
7. The standard must clearly state how the protocol operates in a
hierarchical network.
8. Scalability issues will be considered and analyzed. Very scalable
solutions will be sought. For example, in the case of ATM
technologies, the solution will attempt to conserve VC usage.
Charter Statement:
Currently, none of the solutions that that employ label-swapping based
forwarding ("label switching") in conjunction with network layer
routing are based on standard technology. In order to be able to
achieve the benefits of this new technology, a standard solution is
necessary.
The working group is responsible for standardizing a base technology
for using label swapping forwarding paradigm (label switching) in
conjunction with network layer routing and for the implementation of
that technology over various link level technologies, which may include
Packet-over-Sonet, Frame Relay, ATM, Ethernet (all forms, such as
Gigabit Ethernet, etc.), Token Ring,...
This includes procedures and protocols for the distribution of labels
between routers, encapsulations, multicast considerations, use of
labels to support higher layer resource reservation and QoS mechanisms,
and definition of host behaviors.
Objectives:
1. Specify standard protocol(s) for maintenance and distribution of label
binding information to support unicast destination-based routing with
forwarding based on label-swapping.
2. Specify standard protocol(s) for maintenance and distribution of label
binding information to support multicast routing with
forwarding based on label-swapping.
3. Specify standard protocol(s) for maintenance and distribution of label
binding information to support hierarchy of routing knowledge (e.g.,
complete segregation of intra and inter-domain routing) with forwarding
based on label-swapping.
4. Specify standard protocol(s) for maintenance and distribution of label
binding information to support explicit paths different from the one
constructed by destination-based forwarding with forwarding based on
label-swapping.
5. Specify standard procedures of carrying label information over various
link level technologies.
6. Specify a standard way to use the ATM user plane
a) Allow operation/co-existence with standard (ATM Forum, ITU, etc.)
ATM control plane and/or standard ATM hardware
b) Specify a 'label swapping' control plane
c) Take advantage of possible mods/improvements in ATM
hardware, for example the ability to merge VCs
7. Discuss support for QOS (e.g. RSVP).
8. Define standard protocol(s) to allow direct host (e.g. server)
participation.
Coordination:
The working group will coordinate its activities with other working
groups as appropriate.
Goals and Milestones:
Mar 97 Produce Framework Document Internet-Draft to contain goals with
detailed motivations and description of solution space,
possible approaches
May 97 Submit Framework Document to IESG (Informational RFC)*
May 97 Freeze Internet Draft for carrying label information over
serial lines (p2p links) and over LAN media (e.g., Ethernet,
Token Ring, FDDI)
Jun 97 Submit Achitecture Document to IESG (Informational RFC)
Aug 97 Submit specifications for the protocol to distribute label
binding information for unicast routes to IESG (Standards
Track)
Oct 97 Submit specifications for handling label binding information
(including distribution of this information) for multicast
routes to IESG (Standards Track)
Dec 97 Submit specifications for Operation over ATM to IESG (Standards
Track)
Dec 97 Submit specifications for carrying label information over
serial lines (p2p links) and over LAN media (e.g., Ethernet,
Token Ring, FDDI) to IESG (Standards Track)
Apr 98 Submit procedures for Host Behavior to IESG (Standards Track)
Apr 98 AD review status of WG efforts and determine whether to close
down or not. If not, identify next set of milestones.
Received: from ietf.org by ietf.org id aa07869; 3 Mar 97 16:09 EST
Received: from hiway1.exit109.com by ietf.org id aa07739; 3 Mar 97 16:07 EST
Received: from ppp70-rb.exit109.com (ppp3-rb.exit109.com [205.164.176.130]) by hiway1.exit109.com (8.8.5/8.7.3) with SMTP id QAA17993; Mon, 3 Mar 1997 16:04:39 -0500 (EST)
Received: by ppp70-rb.exit109.com with Microsoft Mail
id <01BC27EC.84AB1160 at ppp70-rb.exit109.com>; Mon, 3 Mar 1997 16:04:05 -0500
Message-ID: <01BC27EC.84AB1160 at ppp70-rb.exit109.com>
Sender:ietf-request at ietf.org
From: "Herman R. Silbiger" <hsilbiger at hiway1.exit109.com>
To: "'ietf at ietf.org'" <ietf at ietf.org>, 'Jon Davis' <mackie at winternet.com>
Subject: RE: MUX Modems (was Re: RFC 1990)
Date: Mon, 3 Mar 1997 15:56:58 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Source-Info: From (or Sender) name not authenticated.
Jon, =20
I suggest that you look at ITU-T Recommendation V.70 (08/96) - =
Procedures for the simultaneous transmission of data and digitally =
encoded voice signals over the GSTN, or over 2-wire leased =
point-to-point telephone type circuits. This standard describes digital =
simultaneous voice and data (DSVD) modems based on the V.34 modem using =
multiplexing and control techniques for use on the switched telephone =
network. Some of these DSVD modems are already commercially available. =
A related standard for a procedure using V.70 for transmitting =
simultaneous voice and facsimile (T.svf) is slated for approval in =
October, 1997.
Herman R. Silbiger
Principal,
APPLICOM
Application and Communication Consultants
T: +1 908 542 1916
F: +1 908 542 5041
hsilbiger at exit109.com
----------
From: Jon Davis[SMTP:mackie at winternet.com]
Sent: Monday, March 03, 1997 1:12 PM
To: ietf at ietf.org
Subject: MUX Modems (was Re: RFC 1990)
I'm a student, not a company. What I'm doing is trying to speculate a
similar (but more basic and more broadly supported) "implementation" so =
to
speak of a single mux modem. Please see
http://www.interact-net.com/think/mux/MUXMODEM.html (and note that I'm =
20
years old, somewhat unfamiliar with low-level networking technospeak, =
and I
had not read RFC 1990 at the time the mux modem model web page above was
produced). It's not an original concept, but it amazes me that modem
companies are not considering the support of multiplexing technology =
over
POTS connections. Forget the requirement of server-side compatibility
keeping it from happening, if US Robotics can successfully pull off x2,
they should be able to successfully pull off POTS multiplexing.
The mux modem model, therefore, would allow the average consumer to come
home with a single modem, plug it in, do basic software-based =
configuration
(plug-n-play), and connect to the Internet or BBS or a friend's computer =
at
twice the bandwidth. The idea here is obviously not multiplexing, which
has been around for decades--maybe as long as a century or more--but =
rather
*single POTS device* and its *marketability for the average consumer*.
I need professional comments on this (as I merely an internet
junkie/hobbiest). Should I study networking technology more and keep
working on this, or am I wasting my time? And why?
Thanks,
Jon
"Perry E. Metzger" <perry at piermont.com> wrote in article
<199702281522.KAA11728 at jekyll.piermont.com>...
>
> Jon Davis writes:
> > Does anyone know where I can get an overview of RFC 1990 written in
PLAIN
> > ENGLISH? I realize it's a technical outline and should only expect =
it
to
> > be written in technical terms, but I was just wondering if anyone
bothered
> > to try to rephrase the article in a clearer presentation than at
> > http://www.neda.com/rfc/rfc1990.txt
>
> It seems pretty reasonable to read to me. If you are having trouble
> with it, maybe you should hire a consultant to help you doing your
> implementation.
>
> Perry
>
Received: from ietf.org by ietf.org id aa12134; 3 Mar 97 16:58 EST
Received: from cnri by ietf.org id aa11885; 3 Mar 97 16:56 EST
Received: from SGI.COM by CNRI.Reston.VA.US id aa16889; 3 Mar 97 16:56 EST
Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA21292 for <@sgi.engr.sgi.com:ietf at nri.reston.va.us>; Mon, 3 Mar 1997 13:54:03 -0800
Received: (from vjs at localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA16441 for ietf at nri.reston.va.us; Mon, 3 Mar 1997 14:53:54 -0700
Date: Mon, 3 Mar 1997 14:53:54 -0700
Sender:ietf-request at ietf.org
From: Vernon Schryver <vjs at mica.denver.sgi.com>
Message-Id: <199703032153.OAA16441 at mica.denver.sgi.com>
To: ietf at CNRI.Reston.VA.US
Subject: Re: don't shoot the messenger
Source-Info: From (or Sender) name not authenticated.
> From: Mark Crispin <MRC at panda.com>
> ...
> > It uses the same mechanism that it
> > always has: "If you don't cooperate I, at least, won't talk to you."
>
> This is a relatively recent phenomenum. In the past, abuse complaints went to
> DCA, who would call the offender on the carpet (as in "show cause why the
> order to pull the plug on your net connection in 4 hours should be reversed").
While that is true of IP connectivity, it is not true of netnews and
UUCP. In that other universe, "go away if you won't play fair" has
been the basic mechanism since the early 1980's.
Even in the ancient IP days, such purely peer-to-peer sanctions were
also used. What is a password for FTP or Telnet except a way to
identify the other guy, and what is killing the connection without the
right password except a form of "play by the rules or a I won't play
with you"?
Vernon Schryver, vjs at sgi.com
Received: from ietf.org by ietf.org id aa14808; 3 Mar 97 17:39 EST
Received: from cnri by ietf.org id aa14592; 3 Mar 97 17:37 EST
Received: from research.circ.gwu.edu by CNRI.Reston.VA.US id aa17650;
3 Mar 97 17:37 EST
Received: from gwis2.circ.gwu.edu (root at gwis2.circ.gwu.edu [128.164.127.252]) by research.circ.gwu.edu (8.8.4/8.6.12) with ESMTP id RAA20044; Mon, 3 Mar 1997 17:33:58 -0500 (EST)
Received: from nimbus ([128.164.12.176]) by gwis2.circ.gwu.edu (8.8.4/8.6.12) with SMTP id RAA04910; Mon, 3 Mar 1997 17:34:24 -0500 (EST)
Message-ID: <331B504A.118F at gwis2.circ.gwu.edu>
Date: Mon, 03 Mar 1997 17:27:22 -0500
Sender:ietf-request at ietf.org
From: Marylin Krupsaw <seap at gwis2.circ.gwu.edu>
Reply-To: seap at gwis2.circ.gwu.edu
Organization: Science & Engineering Apprentice Program
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: ietf at CNRI.Reston.VA.US
CC: seap at gwis2..circ.gwu.edu
Subject: firewalls
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
I'm a student at GWU doing research on firewalls. Please send any
information you have that will help me in assessing how safe firewalls
are for protection. Are firewalls enough to keep hackers and the likes
out.
Received: from ietf.org by ietf.org id aa15243; 3 Mar 97 17:48 EST
Received: from ietf.ietf.org by ietf.org id aa15096; 3 Mar 97 17:45 EST
To: IETF-Announce: ;
Subject: IETF PGP Key Signing Party announcement
Sender:ietf-announce-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
Date: Mon, 03 Mar 1997 17:45:17 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703031745.aa15096 at ietf.org>
Once again, we will be holding a PGP Key signing party at the IETF
meeting in Memphis. We have been scheduled to meet at 2230 (10:30pm) on
the evening of Wednesday, April 9, 1997, in the Lansdown room. The
procedure we will use is the following:
o People who wish to participate should email an ASCII extract of their
PGP public key to <tytso at mit.edu> by 6:00pm on Wednesday of the week
of the IETF meeting. Please include a subject line of "IETF PGP
KEY".
Sending your key to me before the IETF meeting is appreciated, since
it reduces the number of keys that I have to collect during the
meeting. (In fact, why don't you send me your key right now if you
know will be attending, so you won't forget?)
o By 10pm on Wednesday, you will be able to ftp a complete key ring
from tsx-11.mit.edu with all of the keys that were submitted; it will
be in the file /pub/tytso/ietf.asc and /pub/tytso/ietf.pgp.
o At 10:30pm, come prepared with the PGP Key fingerprint of your PGP
public key; we will have handouts with all of the key fingerprints of
the keys that people have mailed in.
o In turn, readers at the front of the room will recite people's keys;
as your key fingerprint is read, stand up, and at the end of reading
of your PGP key fingerprint, acknowledge that the fingerprint as read
was correct.
o Later that evening, or perhaps when you get home, you can sign the
keys corresponding to the fingerprints which you were able to verify
on the handout; note that it is advisable that you only sign keys of
people when you have personal knowledge that the person who stood up
during the reading of his/her fingerprint really is the person which
he/she claimed to be.
o Submit the keys you have signed to the PGP keyservers. A good one to
use is the one at MIT: simply send mail containing the ascii armored
version of your PGP public key to <pgp at pgp.mit.edu>.
Note that you don't have to have a laptop with you; if you don't have
any locally trusted computing resources during the key signing party,
you can make notes on the handout, and then take the handout home and
sign the keys later.
- Ted
Received: from ietf.org by ietf.org id aa20313; 3 Mar 97 19:10 EST
Received: from cnri by ietf.org id aa20199; 3 Mar 97 19:08 EST
Received: from interlock.mgh.com by CNRI.Reston.VA.US id aa19392;
3 Mar 97 19:08 EST
Received: by interlock.mgh.com id AA26843
(InterLock SMTP Gateway 3.0 for ietf at CNRI.Reston.VA.US);
Mon, 3 Mar 1997 19:04:38 -0500
Message-Id: <199703040004.AA26843 at interlock.mgh.com>
Received: by interlock.mgh.com (Protected-side Proxy Mail Agent-1);
Mon, 3 Mar 1997 19:04:38 -0500
Date: Mon, 03 Mar 97 18:33:57 edt
Sender:ietf-request at ietf.org
From: dnewman at mcgraw-hill.com
To: ietf at CNRI.Reston.VA.US
Cc: seap at gwis2..circ.gwu.edu
Subject: Re: firewalls
Source-Info: From (or Sender) name not authenticated.
Sean,
As with all things in engineering, the answer is "it depends." Most
commercial firewalls, when configured properly, do an excellent job of
repelling well-known forms of attack. But that is not the same thing
as saying a network is safe. New attacks are invented all the time,
firewalls are often misconfigured, and disgruntled or unwitting users
may find ways to circumvent a firewall altogether.
This is a complex area, but there are good many good resources
available. The two standard references are "Repelling the Wily
Hacker," by Cheswick and Bellovin (Addison-Wesley), and "Building
Internet Firewalls" by Chapman and Zwicky (O'Reilly and Associates).
I'd also recommend subscribing to the firewalls-digest mailing list
maintained by Brent Chapman. It has a pretty bad signal-to-noise ratio
(lots of pointless religious debate about OSs) but the good stuff
there is very good indeed. To sign up, send e-mail to
majordomo at greatcircle.com with the text "subscribe firewalls-digest"
in the body of the message.
Regards
David Newman
Data Communications magazine
______________________________ Reply Separator _________________________________
Subject: firewalls
Author: seap at gwis2.circ.gwu.edu at CCNODE
Date: 3/3/97 6:00 PM
I'm a student at GWU doing research on firewalls. Please send any
information you have that will help me in assessing how safe firewalls
are for protection. Are firewalls enough to keep hackers and the likes
out.
Received: from ietf.org by ietf.org id aa20470; 3 Mar 97 19:12 EST
Received: from cnri by ietf.org id aa20419; 3 Mar 97 19:12 EST
Received: from interlock.mgh.com by CNRI.Reston.VA.US id aa19484;
3 Mar 97 19:12 EST
Received: by interlock.mgh.com id AA26505
(InterLock SMTP Gateway 3.0 for ietf at CNRI.Reston.VA.US);
Mon, 3 Mar 1997 18:59:41 -0500
Message-Id: <199703032359.AA26505 at interlock.mgh.com>
Received: by interlock.mgh.com (Protected-side Proxy Mail Agent-1);
Mon, 3 Mar 1997 18:59:41 -0500
Date: Mon, 03 Mar 97 18:33:57 edt
Sender:ietf-request at ietf.org
From: dnewman at mcgraw-hill.com
To: ietf at CNRI.Reston.VA.US
Cc: seap at gwis2..circ.gwu.edu
Subject: Re: firewalls
Source-Info: From (or Sender) name not authenticated.
Sean,
As with all things in engineering, the answer is "it depends." Most
commercial firewalls, when configured properly, do an excellent job of
repelling well-known forms of attack. But that is not the same thing
as saying a network is safe. New attacks are invented all the time,
firewalls are often misconfigured, and disgruntled or unwitting users
may find ways to circumvent a firewall altogether.
This is a complex area, but there are good many good resources
available. The two standard references are "Repelling the Wily
Hacker," by Cheswick and Bellovin (Addison-Wesley), and "Building
Internet Firewalls" by Chapman and Zwicky (O'Reilly and Associates).
I'd also recommend subscribing to the firewalls-digest mailing list
maintained by Brent Chapman. It has a pretty bad signal-to-noise ratio
(lots of pointless religious debate about OSs) but the good stuff
there is very good indeed. To sign up, send e-mail to
majordomo at greatcircle.com with the text "subscribe firewalls-digest"
in the body of the message.
Regards
David Newman
Data Communications magazine
______________________________ Reply Separator _________________________________
Subject: firewalls
Author: seap at gwis2.circ.gwu.edu at CCNODE
Date: 3/3/97 6:00 PM
I'm a student at GWU doing research on firewalls. Please send any
information you have that will help me in assessing how safe firewalls
are for protection. Are firewalls enough to keep hackers and the likes
out.
Received: from ietf.org by ietf.org id aa24122; 3 Mar 97 20:32 EST
Received: from cnri by ietf.org id aa23998; 3 Mar 97 20:27 EST
Received: from m3.sprynet.com by CNRI.Reston.VA.US id aa20450;
3 Mar 97 20:27 EST
Received: from jjones (host-159-49.UB.com [128.203.159.49]) by m3.sprynet.com (8.6.12/8.6.12) with SMTP id RAA07873; Mon, 3 Mar 1997 17:24:53 -0800
Message-ID: <331B79AF.BCE at sprynet.com>
Date: Mon, 03 Mar 1997 20:23:59 -0500
Sender:ietf-request at ietf.org
From: Jeff Jones <jdjones at sprynet.com>
Reply-To: jdjones at sprynet.com
X-Mailer: Mozilla 3.0 (WinNT; I)
MIME-Version: 1.0
To: seap at gwis2.circ.gwu.edu
CC: ietf at CNRI.Reston.VA.US
Subject: Re: firewalls
References: <331B504A.118F at gwis2.circ.gwu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Marylin Krupsaw wrote:
>
> I'm a student at GWU doing research on firewalls. Please send any
> information you have that will help me in assessing how safe firewalls
> are for protection. Are firewalls enough to keep hackers and the likes
> out.
>
dnewman at mcgraw-hill.com had some good advice for you. I would add to
that some other thoughts. IMHO, no firewall is 100%. Therefore, there
exists some probability that with any firewall you choose, someone can
get through it. The point, from a security rather than systems view, is
to create a higher path of resistance through your firewall than through
other means.
Firewalls, properly applied (and this takes a thorough plan and
knowledge of the firewall and the system you are trying to protect),
create a very difficult and almost (but not quite) impenetrable point of
entry. Keep in mind what the hacker is looking for.
A. To increase his/her self-esteem by cracking your fortress
B. Espionage (industrial, technological, governmental, etc.) to gain
what you have or cripple your system,
C. Extreme emotional motivation (e.g. revenge of the formerly employed)
A is very rare, but if bright and knowledgable enough, can get through
any firewall. The probability is very low unless your system is a
high-profile system (to help him/her gain notoriety). For example, I
walked into a federal building today, and saw the IP address of a data
server from a terminal being displayed while talking to a clerk.
Knowing that IP address, it becomes infinitely easier to find a way in.
I could tell from the program how they accessed it (Telnet). I did not
write down the address or try to get in because I do not want to spend
time in jail. But it illustrates how very easy some systems people make
it.
B is more likely to go the low tech route, such as gaining access to
your facility as a trojan horse (cleaning person, repairman, etc.) or if
the stakes are high enough, to bribe late night workers (generally
cheaper than paying a hacker).
C is the most dangerous, because they are more likely to know your
system. The best firewall in the world doesn't help if the systems
people are slow to disable remote access. And you would be suprised at
how often administrator passwords are shared discreetly, and find their
way to non-systems people.
Sometimes these profiles are combined in a given individual.
Therefore, when looking for an answer to your question, see the firewall
not as the protection, but as one very important part in an overall
security strategy. Some firewalls may offer marginally better
protection, but not integrate as well as others into an overall security
scheme. One firewall may be the 99% solution, and another the 98%
solution, but the 98% solution, if it worksd better with the existing
systems, system support, and overall security system, would be better
than the 99% solution.
Good luck.
Jeff Jones
Services Manager, CSMC Atlanta
UB Networks
--
=====================================
"He is no fool who gives up what
he cannot keep to gain that
which he cannot lose." - Jim Elliot
=====================================
jdjones at sprynet.com
Received: from ietf.org by ietf.org id aa11800; 4 Mar 97 4:35 EST
Received: from cnri by ietf.org id aa11246; 4 Mar 97 4:25 EST
Received: from sonne.darmstadt.gmd.de by CNRI.Reston.VA.US id aa04039;
4 Mar 97 4:25 EST
Received: from libra.darmstadt.gmd.de (libra [141.12.35.17]) by sonne.darmstadt.gmd.de (8.8.5/8.8.2) with ESMTP id KAA21436; Tue, 4 Mar 1997 10:23:00 +0100 (MET)
Received: from libra (localhost [127.0.0.1]) by libra.darmstadt.gmd.de (8.7.3/8.7.3) with SMTP id KAA27317; Tue, 4 Mar 1997 10:13:52 +0100 (MET)
X-Orig-Sender: schneiw at darmstadt.gmd.de
Message-ID: <331BE7CF.409A at darmstadt.gmd.de>
Date: Tue, 04 Mar 1997 10:13:51 +0100
Sender:ietf-request at ietf.org
From: Wolfgang Schneider <schneiw at darmstadt.gmd.de>
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5 sun4m)
MIME-Version: 1.0
To: seap at gwis2.circ.gwu.edu
CC: ietf at CNRI.Reston.VA.US
Subject: Re: firewalls
References: <331B504A.118F at gwis2.circ.gwu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Marylin,
we prepared an extensive report on firewall technology in the European
ICE-TEL project. You'll find it in
http://www.darmstadt.gmd.de/ice-tel/deliverables
Regards
Wolfgang Schneider
Marylin Krupsaw wrote:
>
> I'm a student at GWU doing research on firewalls. Please send any
> information you have that will help me in assessing how safe firewalls
> are for protection. Are firewalls enough to keep hackers and the likes
> out.
Received: from ietf.org by ietf.org id aa20244; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa18589; 4 Mar 97 9:49 EST
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-duerst-ruby-01.txt
Date: Tue, 04 Mar 1997 09:49:37 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703040949.aa18589 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Ruby in the Hypertext Markup Language
Author(s) : M. Duerst
Filename : draft-duerst-ruby-01.txt
Pages : 7
Date : 03/03/1997
The Hypertext Markup Language (HTML) is a markup language used to create
hypertext documents that are platform independent. Initially HTML was
designed primarily for Western European languages; most of the issues of
basic internationalization to make HTML better usable for other languages
have in the meantime been addressed. Ruby are important phonetic
annotations used mainly for ideographic characters in East Asia. This
document proposes markup for ruby in HTML and explains its usage.
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-duerst-ruby-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-duerst-ruby-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-duerst-ruby-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.
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: <19970303110109.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-duerst-ruby-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-duerst-ruby-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303110109.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20258; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa19322; 4 Mar 97 10:01 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-actng-00.txt
Date: Tue, 04 Mar 1997 10:01:00 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041001.aa19322 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 Roaming Operations Working
Group of the IETF.
Title : The Accounting Problem in Roaming
Author(s) : B. Aboba
Filename : draft-ietf-roamops-actng-00.txt
Pages : 13
Date : 03/03/1997
This document describes the accounting problems that arise in the provision
of inter-provider services, such as provision of dialup roaming
capabilities. These include issues relating to standardization of
accounting record formats, and inter-provider transfers of accounting
record bundles. Work relevant to the solution of these problems are
reviewed, and recommendations are made on the direction of future
standardization work.
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-roamops-actng-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-actng-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-roamops-actng-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: <19970303134501.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-actng-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-actng-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303134501.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20249; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa19230; 4 Mar 97 10:00 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dhcp-v4 at bucknell.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-dhc-v6exts-05.txt
Date: Tue, 04 Mar 1997 10:00:35 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041000.aa19230 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Dynamic Host Configuration
Working Group of the IETF.
Title : Extensions for DHCPv6
Author(s) : C. Perkins
Filename : draft-ietf-dhc-v6exts-05.txt
Pages : 22
Date : 03/03/1997
The Dynamic Host Configuration Protocol for IPv6 [3] (DHCPv6) provides a
framework for passing configuration information to hosts on a TCP/IP
network. Configuration parameters and other control information are
carried in typed data items that are stored in the "extensions" field of
the DHCPv6 message. The data items themselves are also called
"extensions."
This document specifies the current set of DHCPv6 extensions. This
document will be periodically updated as new extensions are defined. Each
superseding document will include the entire current list of valid
extensions.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-v6exts-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-v6exts-05.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-dhc-v6exts-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: <19970303133039.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-v6exts-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-v6exts-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303133039.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20260; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa18638; 4 Mar 97 9:49 EST
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-lewis-dnskey-handling-00.txt
Date: Tue, 04 Mar 1997 09:49:53 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703040949.aa18638 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Zone KEY RRSet Signing Procedure
Author(s) : E. Lewis, O. Gudmundsson
Filename : draft-lewis-dnskey-handling-00.txt
Pages : 7
Date : 03/03/1997
Under the security extensions to DNS, as defined in RFC 2065 and
draft-ietf-dnssec-update-04.txt, a secured zone will have a KEY RRSet
associated with the domain name at the apex of the zone. This document
covers the manner in which this RRSet is generated, signed, and inserted
into the name servers.
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-lewis-dnskey-handling-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-lewis-dnskey-handling-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-lewis-dnskey-handling-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: <19970303125934.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-lewis-dnskey-handling-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-lewis-dnskey-handling-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303125934.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20263; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa18661; 4 Mar 97 9:50 EST
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-mau-mib-04.txt
Date: Tue, 04 Mar 1997 09:50:04 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703040950.aa18661 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 Medium
Attachment Units (MAUs) using SMIv2
Author(s) : K. De Graaf, D. Romascanu, D. McMaster,
K. McCloghrie, S. Roberts
Filename : draft-ietf-hubmib-mau-mib-04.txt
Pages : 48
Date : 03/03/1997
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 10 and 100
Mb/second Medium Attachment Units (MAUs) 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-mau-mib-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-hubmib-mau-mib-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-hubmib-mau-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.
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: <19970303130344.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-hubmib-mau-mib-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-hubmib-mau-mib-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303130344.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20265; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa18678; 4 Mar 97 9:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-ldap-rpcschema-00.txt
Date: Tue, 04 Mar 1997 09:50:16 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703040950.aa18678 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : Lightweight Directory Access Protocol: Schema for
Storing RPC Entries in a Directory Service
Author(s) : S. Judd, S. Thatte, P. Leach, W. Hopkins
Filename : draft-ietf-asid-ldap-rpcschema-00.txt
Pages : 11
Date : 03/03/1997
The Lightweight Directory Access Protocol [1][2] defines a standard
protocol for accessing diverse directory services. One common use of a
directory service is the location of application services, among which are
RPC services.
This document defines a set of object classes and attributes for storing
metadata and binding information for RPC services that are DCE-compliant
or closely follow the DCE model, in directories that support LDAP.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-asid-ldap-rpcschema-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldap-rpcschema-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-asid-ldap-rpcschema-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: <19970303131123.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldap-rpcschema-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldap-rpcschema-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303131123.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20264; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa19371; 4 Mar 97 10:01 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ion at nexen.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ion-mib-01.txt
Date: Tue, 04 Mar 1997 10:01:11 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041001.aa19371 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 : Definitions of Managed Objects for Classical IP and ARP
Over ATM Using SMIv2
Author(s) : M. Greene, J. Luciani, K. White, T. Kuo
Filename : draft-ietf-ion-mib-01.txt
Pages : 34
Date : 03/03/1997
The purpose of this memo is to define the Management Information Base (MIB)
for supporting Classical IP and ARP over ATM as specified in Classical IP
and ARP over ATM, refer to reference [3]. Support of an ATM interface by an
IP layer will require implementation of objects from several Managed
Information Bases (MIBs) as well as their enhancement in order to enable
usage of ATM transports. It is the intent of this MIB to fully adhere to
all prerequisite MIBs unless explicitly stated. Deviations will be
documented in corresponding conformance statements. The specification of
this MIB will utilize the Structure of Management Information (SMI) for
Version 2 of the Simple Network Management Protocol Version (refer to
RFC1902, reference [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-ion-mib-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-mib-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-ion-mib-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.
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: <19970303141517.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303141517.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20268; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa18720; 4 Mar 97 9:51 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dhcp-v4 at bucknell.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-dhc-dhcpv6-09.txt
Date: Tue, 04 Mar 1997 09:50:57 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703040951.aa18720 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Dynamic Host Configuration
Working Group of the IETF.
Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Author(s) : J. Bound, C. Perkins
Filename : draft-ietf-dhc-dhcpv6-09.txt
Pages : 38
Date : 03/03/1997
The Dynamic Host Configuration Protocol (DHCPv6) provides a framework for
passing configuration information, via extensions, to IPv6 nodes. It
offers the capability of automatic allocation of reusable network addresses
and additional configuration flexibility. This protocol should be
considered a stateful counterpart to the IPv6 Stateless Address
Autoconfiguration protocol 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-dhc-dhcpv6-09.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-dhcpv6-09.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-dhc-dhcpv6-09.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
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: <19970303132707.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-dhcpv6-09.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-dhcpv6-09.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303132707.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20261; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa19438; 4 Mar 97 10:01 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: madman 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-madman-mail-monitor-mib-03.txt
Date: Tue, 04 Mar 1997 10:01:29 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041001.aa19438 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail and Directory
Management Working Group of the IETF.
Title : Mail Monitoring MIB
Author(s) : N. Freed
Filename : draft-ietf-madman-mail-monitor-mib-03.txt
Pages : 32
Date : 03/03/1997
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community.
Specifically, this memo extends the basic Network Services Monitoring MIB
[8] to allow monitoring of Message Transfer Agents (MTAs). It may also be
used to monitor MTA components within gateways.
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-madman-mail-monitor-mib-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-madman-mail-monitor-mib-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-madman-mail-monitor-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.
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: <19970303143542.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-madman-mail-monitor-mib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-madman-mail-monitor-mib-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303143542.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20270; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa18609; 4 Mar 97 9:49 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: pktway at myri.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-pktway-protocol-spec-03.txt
Date: Tue, 04 Mar 1997 09:49:45 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703040949.aa18609 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 PacketWay Working Group of
the IETF.
Title : Proposed Specification for the PacketWay Protocol
Author(s) : D. Cohen, C. Lund, T. Skjellum,
T. McMahon, R. George
Filename : draft-ietf-pktway-protocol-spec-03.txt
Pages : 37
Date : 03/03/1997
PacketWay's goal is to move data from a "Source" (a node on a System Area
Network) to a "Destination" (another node, probably on another System Area
Network) at the high performance available on these SANs. Sources and
Destinations can be physical things (a processor or a smart memory board).
They can also be "logical" things, such as a group of cooperating
processes.
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-pktway-protocol-spec-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pktway-protocol-spec-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-pktway-protocol-spec-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.
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: <19970303112516.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pktway-protocol-spec-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pktway-protocol-spec-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303112516.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21150; 4 Mar 97 10:11 EST
Received: from ietf.ietf.org by ietf.org id aa19294; 4 Mar 97 10:00 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-radius at livingston.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-radius-tunnel-imp-00.txt
Date: Tue, 04 Mar 1997 10:00:53 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041000.aa19294 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 Remote Authentication
Dial-In User Service Working Group of the IETF.
Title : Implementation of Mandatory Tunneling via RADIUS
Author(s) : B. Aboba, G. Zorn
Filename : draft-ietf-radius-tunnel-imp-00.txt
Pages : 17
Date : 03/03/1997
This document discusses implementation issues arising in the provisioning
of mandatory tunneling in dial-up networks using the PPTP and L2TP
protocols. This provisioning may be accomplished via the integration of
RADIUS and tunneling protocols.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-radius-tunnel-imp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-radius-tunnel-imp-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-radius-tunnel-imp-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: <19970303134140.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-radius-tunnel-imp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-radius-tunnel-imp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303134140.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21179; 4 Mar 97 10:11 EST
Received: from ietf.ietf.org by ietf.org id aa20409; 4 Mar 97 10:08 EST
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-freed-smtp-pipeline-01.txt
Date: Tue, 04 Mar 1997 10:08:38 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041008.aa20409 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : SMTP Service Extension for Command Pipelining
Author(s) : N. Freed
Filename : draft-freed-smtp-pipeline-01.txt
Pages : 9
Date : 03/03/1997
This memo defines an extension to the SMTP service whereby a server can
indicate the extent of its ability to accept multiple commands in a single
TCP send operation. Using a single TCP send operation for multiple commands
can improve SMTP performance significantly.
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-freed-smtp-pipeline-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-freed-smtp-pipeline-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-freed-smtp-pipeline-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.
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: <19970303145546.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-freed-smtp-pipeline-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-freed-smtp-pipeline-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303145546.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ab21150; 4 Mar 97 10:11 EST
Received: from ietf.ietf.org by ietf.org id aa19355; 4 Mar 97 10:01 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-dnsrr-01.txt
Date: Tue, 04 Mar 1997 10:01:06 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041001.aa19355 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 Roaming Operations Working
Group of the IETF.
Title : The Roaming Relationship (RR) Record in the DNS
Author(s) : B. Aboba
Filename : draft-ietf-roamops-dnsrr-01.txt
Pages : 15
Date : 03/03/1997
This document describes the use of the Roaming Relationship (RR) record in
the DNS for the description of roaming relationships. In the absence of DNS
security, RR records may be used for determining the existence of a roaming
relationship path between the local ISP and the user's home domain, as well
as the location of an appropriate accounting agent. However, since the RR
records are not secured, other methods (such as hierarchical authentication
routing) must be used in order to validate the roaming relationship path.
When DNS security is implemented, the roaming relationship path is
authenticated via digital signatures, and as a result, additional services
may be provided, such as non-repudiation of proxied authentications and
signed receipts for accounting record transfers.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-dnsrr-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-dnsrr-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-roamops-dnsrr-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.
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: <19970303140946.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-dnsrr-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-dnsrr-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303140946.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21344; 4 Mar 97 10:11 EST
Received: from ietf.ietf.org by ietf.org id aa20471; 4 Mar 97 10:08 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dhcp-v4 at bucknell.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-dhc-fqdn-opt-02.txt
Date: Tue, 04 Mar 1997 10:08:57 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041008.aa20471 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Dynamic Host Configuration
Working Group of the IETF.
Title : An option for FQDNs in DHCP options
Author(s) : Y. Rekhter, R. Droms
Filename : draft-ietf-dhc-fqdn-opt-02.txt
Pages : 4
Date : 03/03/1997
DHCP [DHCP] can be used to automate the process of configuring TCP/IP host
computers. However, some of the DHCP options carry IP addresses rather
than Fully Qualified Domain Names (FQDN). Use of IP addresses constrains
the DHCP client to use the addresses that were in use at the time the
client received its configuration information; these addresses may change
over time, (e.g., a server may be assigned a new IP address), so that the
IP addresses used by the client may become invalid.
An alternative to passing IP addresses is to pass FQDNs instead of
(numeric) IP addresses. Doing this allows to defer binding between a
particular network entity (e.g., a server) and its IP address until run
time. As stated in [Carpenter:96], "Deferring the binding avoids the risk
of changed mapping between IP addresses and specific network entities (due
to changing addressing information). Moreover, reliance on FQDNs (rather
than IP addresses) also localizes to the DNS the changes needed to deal
with changing addressing information due to renumbering."
This document defines a new DHCP option that allows the use of FQDNs
instead of IP addresses in DHCP options.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-fqdn-opt-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-fqdn-opt-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-dhc-fqdn-opt-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: <19970303170819.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-fqdn-opt-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-fqdn-opt-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303170819.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21436; 4 Mar 97 10:11 EST
Received: from ietf.ietf.org by ietf.org id aa20436; 4 Mar 97 10:08 EST
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-rosen-tag-stack-01.txt
Date: Tue, 04 Mar 1997 10:08:48 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041008.aa20436 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Label Switching: Label Stack Encodings
Author(s) : E. Rosen, Y. Rekhter, D. Tappan,
D. Farinacci, G. Fedorkow
Filename : draft-rosen-tag-stack-01.txt
Pages : 17
Date : 03/03/1997
"Label Switching" [1] requires a set of procedures for augmenting network
layer packets with "Label Stacks" (formerly called "Tag Stacks"), thereby
turning them into "Labeled packets". This document specifies the encoding
to be used, on PPP data links and LAN data links, in order to produce a
Labeled packet from a Label Stack and a network layer packet.
This document also specifies rules and procedures for processing the
various fields of the Label Stack encoding.
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-rosen-tag-stack-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rosen-tag-stack-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-rosen-tag-stack-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.
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: <19970303152448.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rosen-tag-stack-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rosen-tag-stack-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303152448.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20262; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa18612; 4 Mar 97 9:49 EST
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-ipsec-doi-02.txt
Date: Tue, 04 Mar 1997 09:49:49 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703040949.aa18612 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 : The Internet IP Security Domain of Interpretation
for ISAKMP
Author(s) : D. Piper
Filename : draft-ietf-ipsec-ipsec-doi-02.txt
Pages : 20
Date : 03/03/1997
The Internet Security Association and Key Management Protocol (ISAKMP)
defines a framework for security association management and cryptographic
key establishment for the Internet. This framework consists of defined
exchanges and processing guidelines that occur within a given Domain of
Interpretation (DOI). This document details the Internet IP Security DOI,
which is defined to cover the IP security protocols that use ISAKMP to
negotiate their security associations.
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-ipsec-doi-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ipsec-doi-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-ipsec-ipsec-doi-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: <19970303120116.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-ipsec-doi-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303120116.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20259; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa18572; 4 Mar 97 9:49 EST
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-floyd-distributed-search-01.txt
Date: Tue, 04 Mar 1997 09:49:31 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703040949.aa18572 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Distributed Search Management Protocol
Author(s) : J. Floyd
Filename : draft-floyd-distributed-search-01.txt
Pages : 15
Date : 03/03/1997
There are a number of instances in which the search for a particular value
(for instance, a cryptographic key) can be distributed across a large
number of machines, however there is not currently a standard protocol for
doing so. A great many algorithms may be used for searches; because these
algorithms may differ greatly, the protocol used must be flexible enough to
be easily extended.
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-floyd-distributed-search-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-floyd-distributed-search-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-floyd-distributed-search-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.
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: <19970303100406.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-floyd-distributed-search-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-floyd-distributed-search-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303100406.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21439; 4 Mar 97 10:11 EST
Received: from ietf.ietf.org by ietf.org id aa20376; 4 Mar 97 10:08 EST
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-freed-pvcsc-02.txt
Date: Tue, 04 Mar 1997 10:08:33 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041008.aa20376 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : MIME Parameter Value and Encoded Word Extensions:
Character Sets, Languages, and Continuations
Author(s) : N. Freed, K. Moore
Filename : draft-freed-pvcsc-02.txt
Pages : 10
Date : 03/03/1997
This memo defines extensions to the RFC 2045 media type and RFC CDISP
disposition parameter value mechanisms to provide (1) a means to specify
parameter values in character sets other than US-ASCII, (2) to specify
the language to be used should the value be displayed, and (3)
a continuation mechanism for long parameter values to avoid
problems with header line wrapping.
This memo also defines an extension to the encoded words defined in RFC
2047 to allow the specification of the language to be used for display as
well as the character set.
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-freed-pvcsc-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-freed-pvcsc-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-freed-pvcsc-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: <19970303145238.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-freed-pvcsc-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-freed-pvcsc-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303145238.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21481; 4 Mar 97 10:11 EST
Received: from ietf.ietf.org by ietf.org id aa20498; 4 Mar 97 10:09 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: frs-mib at newbridge.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-frnetmib-dcp-00.txt
Date: Tue, 04 Mar 1997 10:09:02 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041009.aa20498 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 Frame Relay Service MIB
Working Group of the IETF.
Title : Management Information Base for Frame Relay DTE
Extensions for Data Compression over Frame Relay
Author(s) : M. Kashef, J. Colom
Filename : draft-ietf-frnetmib-dcp-00.txt
Pages : 8
Date : 03/03/1997
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 Data Compression over a Frame
Relay virtual circuit. 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-frnetmib-dcp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-frnetmib-dcp-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-frnetmib-dcp-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: <19970303171503.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-frnetmib-dcp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-frnetmib-dcp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303171503.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21473; 4 Mar 97 10:11 EST
Received: from ietf.ietf.org by ietf.org id aa20453; 4 Mar 97 10:08 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: urn-ietf at bunyip.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-urn-syntax-03.txt
Date: Tue, 04 Mar 1997 10:08:53 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041008.aa20453 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 Uniform Resource Names
Working Group of the IETF.
Title : URN Syntax
Author(s) : R. Moats
Filename : draft-ietf-urn-syntax-03.txt
Pages : 7
Date : 03/03/1997
Uniform Resource Names (URNs) are intended to serve as persistent,
location-independent, resource identifiers. This document sets forward the
canonical syntax for URNs. A discussion of both existing legacy and new
namespaces and requirements for URN presentation and transmission are
presented. Finally, there is a discussion of URN equivalence and how to
determine it.
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-urn-syntax-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-urn-syntax-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.
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: <19970303164344.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-urn-syntax-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-urn-syntax-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303164344.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22723; 4 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa20329; 4 Mar 97 10:08 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: madman 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-madman-nsm-mib-04.txt
Date: Tue, 04 Mar 1997 10:08:28 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041008.aa20329 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail and Directory
Management Working Group of the IETF.
Title : Network Services Monitoring MIB
Author(s) : N. Freed
Filename : draft-ietf-madman-nsm-mib-04.txt
Pages : 22
Date : 03/03/1997
A networked application is a realization of some well defined service on
one or more host computers that is accessible via some network, uses some
network for its internal operations, or both.
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-madman-nsm-mib-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-madman-nsm-mib-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-madman-nsm-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.
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: <19970303144906.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-madman-nsm-mib-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-madman-nsm-mib-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303144906.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29555; 4 Mar 97 11:25 EST
Received: from ietf.ietf.org by ietf.org id aa29194; 4 Mar 97 11:21 EST
To: ietf at ietf.org
Subject: Re: Forging subscriptions - was Re: Remove us from the mailing list
Sender:ietf-request at ietf.org
From: Frank de Lange <frank at animalhouse.ml.org>
Date: Tue, 04 Mar 1997 11:21:21 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703041121.aa29194 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
> >Forging people's names on subscriptions to mailing lists is becoming a
> >daily occurance....
>
> Just a thought, not to start a deep technical thread on the general list.
>
> Without being able to authenicate the subscription requestor (at this
> time), could a tape-and-glue fix be as simple as: when a request for
> subscription is received, a confirmation is requested (i.e., in a mail
> message to the subscribing address), and until a returned confirmation is
> received, the subscription is not made? I've heard that this approach is
> being used with at least one (non-IETF) mail list.
>
> A forger would have to be in the path of the forged address to see the
> confirmation message. To prevent predicatability of the confirmation a
> somewhat random phrase could be used in the confirmation request and reply.
This does indeed work, a mechanism like this is in use at several sites (an
example of which is ml.org (Monolith), which uses a three-way handshake to
authenticate `subscribers' to their services (free DNS listings, but the same
principle is valid in any other service).
Frank
WWWWW ___________________________
## o o\ / Frank de Lange \
}# \| / +31-70-3712708 day \
##---# _/ +31-320-252965 night \
#### \frank.de.lange at inet.unisource.nl/
\ frank.de.lange at net.info.nl /
------------------------------
Received: from ietf.org by ietf.org id aa04759; 4 Mar 97 12:21 EST
Received: from cnri by ietf.org id aa04586; 4 Mar 97 12:19 EST
Received: from black-ice.cc.vt.edu by CNRI.Reston.VA.US id aa12384;
4 Mar 97 12:19 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id MAA21708;
Tue, 4 Mar 1997 12:16:14 -0500
Message-Id: <199703041716.MAA21708 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: jdjones at sprynet.com
Cc: seap at gwis2.circ.gwu.edu, ietf at CNRI.Reston.VA.US
Subject: Re: firewalls
In-Reply-To: Your message of "Mon, 03 Mar 1997 20:23:59 EST."
<331B79AF.BCE at sprynet.com>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <331B504A.118F at gwis2.circ.gwu.edu>
<331B79AF.BCE at sprynet.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1659436632P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 04 Mar 1997 12:16:13 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_1659436632P
Content-Type: text/plain; charset=us-ascii
On Mon, 03 Mar 1997 20:23:59 EST, Jeff Jones said:
> entry. Keep in mind what the hacker is looking for.
> A. To increase his/her self-esteem by cracking your fortress
> B. Espionage (industrial, technological, governmental, etc.) to gain
> what you have or cripple your system,
> C. Extreme emotional motivation (e.g. revenge of the formerly employed)
>
> A is very rare, but if bright and knowledgable enough, can get through
> any firewall. The probability is very low unless your system is a
Umm.. you overlooked (D) the lamer d00d with a bunch of hacking
scriptz that he doesn't even understand, just plug-and-chug hacking
because they don't have a life. Fortunately, most of them never
graduate from category (D) to category (A), and a reasonable *and well
implemented* security policy will stop most of them. On the other
hand, I have heard from a number of sources that Kevin Mitnick's TCP
sequence number hacks were written by somebody else, and Mitnick just
social-engineered the a copy of the script for himself. So care *is*
needed.
Unfortunately, I work in a university environment, where there's a lot
of machines in departments that don't have a clue. And it's
politically impossible to require proof of clue ownership (beyond
being able to plug in a 10BaseT connector) before letting users on the
net....
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_1659436632P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMxxY29QBOOoptg9JAQHliwP/Y0t+CRs/p2TXDbyzegNhui4QnrFE8SYv
tfx6jUE6QDTPBr0TYHx85lfnPx37oB0oKmxX86nuKDRFeSEXuO8p6JRvthPUbAiG
aumxmXsLUbFm2WmkExuGcHA9BGTxxI6rX3Yu3sHBZvpehwlsmj3n78L4HGbf8AqC
5OdwN5/0vlY=
=wXxq
-----END PGP MESSAGE-----
--==_Exmh_1659436632P--
Received: from ietf.org by ietf.org id aa06246; 4 Mar 97 12:41 EST
Received: from cnri by ietf.org id aa06118; 4 Mar 97 12:38 EST
Received: from soleil.uvsq.fr by CNRI.Reston.VA.US id aa13091;
4 Mar 97 12:38 EST
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id SAA20405
; Tue, 4 Mar 1997 18:26:55 +0100 (MET)
Sender:ietf-request at ietf.org
From: 2IN97 at prism.uvsq.fr
Received: from davoult.prism.uvsq.fr (davoult.prism.uvsq.fr [193.51.25.134])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with SMTP id RAA19259
for <congres>; Tue, 4 Mar 1997 17:48:43 +0100 (MET)
Message-ID: <331C5126.56FA at prism.uvsq.fr>
Date: Tue, 04 Mar 1997 17:43:18 +0100
Organization: Prism
X-Mailer: Mozilla 3.0Gold (Win95; I)
MIME-Version: 1.0
To: congres at prism.uvsq.fr
Subject: Call for papers 2IN97
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by soleil.uvsq.fr id SAA20405
Source-Info: From (or Sender) name not authenticated.
________________________________________________________________________
We apologize for multiple copies=20
________________________________________________________________________
CALL FOR PAPERS
1997 International Conference
Intelligent Networks and Intelligence in Networks
=20
(2IN97)
Paris - France=20
September 2-5, 1997
Organizer : IFIP TC WG 6.7 - Intelligent Networks
Sponsorship requested : Alcatel, Ericsson, France Telecom, Nokia, Nordic
teleoperators, Siemens, Telecom Finland, Lab. PRiSM
Aim of the conference
To identify and study current issues related to the development of
intelligent capabilities in networks. These issues include the
development and distribution of services in broadband and mobile
networks.
This conference belongs to a series of IFIP conference on Intelligent
Network. The first one took place in Lappeeranta August 94, the second
one in Copenhagen, August 95. The proceedings of both events have been
published by Chapman&Hall.
IFIP Working Group 6.7 on IN has concentrated with the research and
development of Intelligent Networks architectures. First the activities
have concentrated in service creation, service management, database
issues, feature interaction, IN performance and advanced signaling for
broadband services. Later on the research activities have turned towards
the distribution of intelligence in networks and IN applications to
multimedia and mobility. The market issues of new services have also
been studied. From the system development point of view, topics from OMG
and TINA-C have been considered.
Main fields of interest to 2IN97:
IN Markets and trends
- Value added services market=20
- Development in telecom area
- Multimedia IN
- IN and the Internet
Standardization/integration and legacies
- Standardization aspects
- TINA
- IN and B-ISDN
- IN and mobile networks
- Intelligence in ATM networks
Service types, service architecture and=20
- Service creation, distribution and management
- IN service architecture
- Service creation architecture applied in multimedia services (voice,
data, mobile)
- Multimedia services
Tools
- Intelligent control schemes
- Multimedia call models
- Multimedia call control protocols
- Intelligent routing
- Continuous media
- Performance issues
- Intelligent agents
- Distributed artificial intelligence and multi-agent systems for
networks
- JAVA technology for IN services
IN systems and platforms
- IN architecture
- Intelligence and Network Management
- Real time data bases and caches for services
Workshop organization
Lab PRiSM (University of Versailles)
Place of the conference : French Ministry of Telecommunication, Avenue
de Segur, Paris, France
Conference chair:=20
Olli Martikainen FIN=20
Guy Pujolle F
Program committee chair :
Dominique Ga=EFti F
Program committee members
James Aitken UK
Almeida Maria J.B. BR
Andy Bihain USA
Gilles Bregant F
Carla Capellmann, GER
Christian Chabernaud F
Peter Delgado UK
Heinz Dibold GER
Jacques Ferber F
Frank Gallivan USA
Philip Ginzboorg FIN
Shri Goyal USA
Serge Haddad F
Heikki Hammainen FIN
Villy Baek Iversen DK
Bijan Jabbari USA
Jorma Jormakka FIN
Koos Koen RSA
Ulf K=F6rner S
Paul K=FChn GER
Roberto Kung F
Jacques Labetoulle F
Xuejia Lai CH
Martine Lapierre F
Kari Lautanala FIN
Aurel A. Lazar USA
Olli Martikainen FIN=20
Valeri A. Naoumov RF
Karl W. Neunast GER
Jorgen Norgaard DK
Herv=E9 Precioso F
Guy Pujolle F
Kimmo Raatikainen FIN
Konstantin E. Samouylov RF
Manfred Schneps-Schneppe RUS
Lennart S=F6derberg S
Haitao Tang CN
Organization chair :
Nadia Boukhatem F
Thierry Hua F
Important dates:
March 21, 1997: Deadline for Paper Submission
May 15, 1997: Notification of Acceptance
July 1, 1997: Final Version Due
September 2, 1997: Tutorial
September 3-5, 1997: Conference
Instructions:
Submit five copies of a full paper by March 21, 1997. Papers should be
no longer than 20 double spaced typewritten pages, including tables and
figures. The proceedings will be published by Chapman&Hall
All correspondence should be addressed:
- by email (postcript version of the paper) - 2IN97 at prism.uvsq.fr
- or by mail to
2IN97 Conference
Lab PRiSM - University of Versailles
45 av. des Etats-Unis
78035 Versailles Cedex - France
------------------------------------------------------------------------
2IN'97
1st Name: ..............................................................
Last Name:..............................................................
email:..................................................................
Title:..................................................................
Organization:...........................................................
Postal address:.........................................................
........................................................................
City:..............................Postal code:.........................
Country:................................................................
Telephone:..............................................................
Fax:....................................................................
O Topics I am interested in:............................................
O I wish to attend the ICCC'97 conference.
O I wish to present a paper and will submit a paper by March 21, 1997.=20
Title of the paper :
........................................................................
........................................................................
........................................................................
________________________________________________________________________
________________________________________________________________________
Received: from ietf.org by ietf.org id aa14344; 4 Mar 97 13:52 EST
Received: from cnri by ietf.org id aa14244; 4 Mar 97 13:50 EST
Received: from m3.sprynet.com by CNRI.Reston.VA.US id aa15070;
4 Mar 97 13:50 EST
Received: from jjones (host-159-49.UB.com [128.203.159.49]) by m3.sprynet.com (8.6.12/8.6.12) with SMTP id KAA08150; Tue, 4 Mar 1997 10:48:19 -0800
Message-ID: <331C6E3C.5BD4 at sprynet.com>
Date: Tue, 04 Mar 1997 13:47:24 -0500
Sender:ietf-request at ietf.org
From: Jeff Jones <jdjones at sprynet.com>
Reply-To: jdjones at sprynet.com
X-Mailer: Mozilla 3.0 (WinNT; I)
MIME-Version: 1.0
To: Valdis.Kletnieks at vt.edu
CC: ietf at CNRI.Reston.VA.US
Subject: Re: firewalls
References: <331B504A.118F at gwis2.circ.gwu.edu>
<331B79AF.BCE at sprynet.com> <199703041716.MAA21708 at black-ice.cc.vt.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Valdis.Kletnieks at vt.edu wrote:
>
> On Mon, 03 Mar 1997 20:23:59 EST, Jeff Jones said:
> > entry. Keep in mind what the hacker is looking for.
> > A. To increase his/her self-esteem by cracking your fortress
> > B. Espionage (industrial, technological, governmental, etc.) to gain
> > what you have or cripple your system,
> > C. Extreme emotional motivation (e.g. revenge of the formerly employed)
> >
> > A is very rare, but if bright and knowledgable enough, can get through
> > any firewall. The probability is very low unless your system is a
>
> Umm.. you overlooked (D) the lamer d00d with a bunch of hacking
> scriptz that he doesn't even understand, just plug-and-chug hacking
> because they don't have a life. Fortunately, most of them never
> graduate from category (D) to category (A), and a reasonable *and well
> implemented* security policy will stop most of them. On the other
> hand, I have heard from a number of sources that Kevin Mitnick's TCP
> sequence number hacks were written by somebody else, and Mitnick just
> social-engineered the a copy of the script for himself. So care *is*
> needed.
>
> Unfortunately, I work in a university environment, where there's a lot
> of machines in departments that don't have a clue. And it's
> politically impossible to require proof of clue ownership (beyond
> being able to plug in a 10BaseT connector) before letting users on the
> net....
>
> --
> Valdis Kletnieks
> Computer Systems Engineer
> Virginia Tech
>
> ---------------------------------------------------------------
>
> Part 1.2 Type: application/pgp-signature
--
I agree - I guess I just lumped D's with A's - an insult to A's
everywhere. Consider me dutifully penitent.
Jeff Jones
=====================================
"He is no fool who gives up what
he cannot keep to gain that
which he cannot lose." - Jim Elliot
=====================================
jdjones at sprynet.com
Received: from ietf.org by ietf.org id aa14343; 4 Mar 97 13:52 EST
Received: from cnri by ietf.org id aa13904; 4 Mar 97 13:49 EST
Received: from postbox.dai.ed.ac.uk by CNRI.Reston.VA.US id aa15040;
4 Mar 97 13:49 EST
Received: from sole (sole.dai.ed.ac.uk [192.41.107.4]) by postbox.dai.ed.ac.uk (8.6.13/8.6.12) with ESMTP id SAA06568; Tue, 4 Mar 1997 18:36:29 GMT
Sender:ietf-request at ietf.org
From: michael at dai.ed.ac.uk
Date: Tue, 4 Mar 1997 18:34:31 GMT
Message-Id: <7578.199703041834 at sole>
To: BENKING at faw.uni-ulm.de, E.Slarke at unsw.edu.au, EricT at cov.ac.uk,
Guy.VanBelle at rug.ac.be, IETF at CNRI.Reston.VA.US,
J.L.Leach at maths.bath.ac.uk, M.North at lcad.ac.uk, N.G.Cross at open.ac.uk,
N.Oloughlin at lcad.ac.uk, Pcrofts at chelt.ac.uk, Peter.Thomas at csm.uwe.ac.uk,
S.M.Loke at u.ac.shef.ac.uk, WGODWIN at chelt.ac.uk, alg at comm.toronto.edu,
armin at mic.atr.co.jp, atm at bbn.com, bota at race.u-tokyo.ac.jp,
cabernet-general at newcastle.ac.uk, ccrc at dworkin.wustl.edu,
cost237-transport at comp.lancs.ac.uk, ed1 at mdx.ac.uk, enternet at bbn.com,
fokus-user at fokus.gmd.de, giga at tele.pitt.edu, hipparch at sophia.inria.fr,
hoffmann at osiris.iemar.tuwien.ac.at, isadsoc at fokus.gmd.de,
jwworth at jupiter.informatik.umu.se, knishi at mic.atr.co.jp,
multicomm at cc.bellcore.com, osimcast at bbn.com,
performance at haven.epm.ornl.gov, rafaelp at cogs.susx.ac.uk, rem-conf at es.net,
reres at laas.fr, sbell at bmth.ac.uk, schmid at dfki.uni-kl.de,
sigmedia at bellcore.com, sugi at rd.nacsis.ac.jp, tccc at cs.umass.edu,
urban at egd.igd.fhg.de, xtp-relay at cs.concordia.ca, yevin at sam.imash.ras.ru
Subject: EuropIA
Source-Info: From (or Sender) name not authenticated.
europia`97
@EDINBURGH
------------------
DESIGN and the NET
------------------
http://www.caad.ed.ac.uk/europia/
Details and Provisional Programme
---------------------------------
Sixth International Conference on the Application/Implications of Computer
Networking in Architecture, Construction, Design, Civil Engineering and
Urban Planning
Sixime Confrence Internationale sur les applications/implications des
nouvelles technologies de communication en Architecture, Construction,
Design, Ingnierie et Planification urbaine
2-3 April 1997
Department of Architecture
University of Edinburgh
Edinburgh EH1 1JZ Scotland
http://www.caad.ed.ac.uk/europia/
This conference brings together researchers in design, architecture,
engineering, construction management, cognitive science, computer science,
artificial intelligence, sociology, geography and education as well as
industry partners, practitioners and other users of networked
communications.
The focus for this diverse group is design - how we design with and for
networked communications - appropriating recent exciting developments in
medium and broad band local area and wide area networks, new protocols for
interaction and new communications tools such as Web browsers and network
aware multimedia tools.
DATES
Conference 2-3 April 1997
REGISTRATION FEE
Authors 175 pounds stirling
Non-authors 250 pounds stirling
Conference Dinner 27 pounds stirling
VENUE
UnivEd Training and Conference Centre
11 South College Street
Edinburgh EH8 9AA
SEND QUEURIES ABOUT REGISTRATION AND ACCOMMODATION TO
Ronnie Galloway
Conference Manager
Ronnie.Galloway at ed.ac.uk
UnivEd Technologies Limited
11 South College Street, Edinburgh, EH8 9AA
Ph +44 131 650 9020
Fax +44 131 650 9019
EuropIA'97 Design and the Net 2-3 April 1997
+++++++++++++++++++++++++++++++++++++++++
Provisional Programme
=====================
(4/3/97)
Wednesday
9.15-9.30 Welcome
Working with the web: Networked CAD applications
9.30-10.00 . Common libraries for networked engineering
applications
Tuttle et al
10.00-10.30 . The VRML model of the city of Bath
Bourdakis and Day
10.30-11.00 break
11.00-11.30 . Shared information system for urban and architectural
design
Caneparo
11.30-12.00 . Communication in distributed statistical frameworks
for historic building documentation: The abbey of
Valmagne
Warden & Vasquez
12.00-12.30 . CAD On-line
Coyne & Lee
12.30-2.00 lunch
Working with the web: Innovation and technology
2.00-2.30 . A method for organising and sharing architectural
project information in the WWW
Ofluoglu & Kalisperis
2.30-3.00 . Designing learning environments using java
Pang & Edmonds
3.00-3.30 . A web -based design support environement for knowledge
discovery and machine learning
Branki, Bridges, Wallis & Aird
3.30-4.00 break
4.00-4.30 . Ways of aiding navigation in VRML worlds
Caritos and Rutherford
4.30-5.00 . Multilevel representations of architectural designs
Koutamanis
5.00-5.30 . A network aid for design project management
Roussel & Zriek
Thursday
The web in practice: Education in cyberspace
9.30-10.00 . The tex-mex virtual design studio
Vasquez & Trigo
10.00-10.30 . Networked based decision support for building design
Burry & Smithers
10.30-11.00 . Digital design: students communicating experiential
spatial qualities in a networked computing environment
Burley, Megza & Bauer
11.00-11.30 break
The web in practice: The emerging webculture
11.30-12.00 . HQ video conferencing and its application to the
teaching of architecture
Lindsay & Grant
12.00-12.30 . Sedimented practices of 'reading' design descriptions:
from paper to screen
Tweed
12.30-1.00 . The architect's role in the information age
Rossis
1.00-2.00 lunch
2.00-2.30 . Collaborative design by discovery and the web
Peng
2.30-3.00 . Method DTN: Design through the net
Reze
3.00-3.30 . A cyberspace in time
Szalapaj & Filho
3.30-4.30 Poster Session
The web in practice: The emerging webculture (cont.)
4.30-5.00 . A virtual monoculture of visual communication
Newton & Shi
5.00-5.30 . Design information and the superhighway:
roadworks ahead?
Ramscar & Lee
5.30-6.00 Plenary Session
Poster Session
. A web based experience of a collaborative
argumentation system design
Chen, Branki & Newman
. Networked collaborative design implementation
Burry, Coll & Serrano
. Up the down staircase...
Brady
. Broadband videoconference workstation
Brandt et al
. DesignNet electronic journal
Westphal & Burley
. Cybernetic theory & architecture
Hunt
. Intranets as tools for strategy
Thomas
. Building an intranet model for CAAD
Paranandi
Received: from cnri by ietf.org id aa21459; 4 Mar 97 15:40 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17238;
4 Mar 97 15:40 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA00194 at pad-thai.cam.ov.com>; Tue, 4 Mar 1997 18:27:48 GMT
Message-Id: <3.0.32.19970304102541.006aa868 at pop-srvr>
X-Sender: arim at pop-srvr
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 04 Mar 1997 10:25:42 -0800
To: cat-ietf at mit.edu
From: Ari Medvinsky <ari.medvinsky at cybersafe.com>
Subject: Re: Memphis agenda and discussion solicitation
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Hello,
Recently Matt Hur, Clifford Neuman and I published an internet draft:
Public Key Utilizing Tickets for Application Servers (PKTAPP:=20
draft-ietf-cat-pktapp-00.txt ). We plan on giving a presentation at the
next CAT group meeting, and would like to solicit comments and discussion=
=20
prior to the IETF.=20
Abstract:
Public key based Kerberos for Distributed Authentication, (PKDA)=20
proposed by Sirbu & Chuang, describes PK based authentication that=20
eliminates the use of a centralized key distribution center while=20
retaining the advantages of Kerberos tickets. This draft describes how,
without any modification, the PKINIT specification may be used to=20
implement the ideas introduced in PKDA. The benefit is that only a=20
single PK Kerberos extension is needed to address the goals of PKINIT &=20
PKDA.
Given that PKINIT has progressed through the CAT working group of the=20
IETF, with plans for non-commercial distribution (via MIT's v5 Kerberos) =
=20
as well as plans for commercial support, we believe that it is worthwhile=
to=20
provide PKDA functionality under the PKINIT umbrella.
Regards,
-Ari
a copy of the PKTAPP draft is provided below:
---------------------------------------------------------------
INTERNET-DRAFT Ari Medvinsky
Common Authentication Technology Working Group Matthew Hur
draft-ietf-cat-pktapp-00.txt CyberSafe Corporation
B. Clifford Neuman
USC/ISI
Jan. 97 (Expires July-97)
Public Key Utilizing Tickets for Application Servers (PKTAPP)
0. Status Of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
1. Abstract
Public key based Kerberos for Distributed Authentication[1], (PKDA)=20
proposed by Sirbu & Chuang, describes PK based authentication that=20
eliminates the use of a centralized key distribution center while=20
retaining the advantages of Kerberos tickets. This draft describes how,
without any modification, the PKINIT specification[2] may be used to=20
implement the ideas introduced in PKDA. The benefit is that only a=20
single PK Kerberos extension is needed to address the goals of PKINIT &=20
PKDA.
=20
2. Introduction
With the proliferation of public key cryptography, a number of public=20
key extensions to Kerberos have been proposed to provide=20
interoperability with the PK infrastructure and to improve the Kerberos=20
authentication system [4]. Among these are PKINIT[2] (under development=20
in the CAT working group) and more recently PKDA [1] proposed by Sirbu &=20
Chuang of CMU. One of the principal goals of PKINIT is to provide for=20
interoperability between a PK infrastructure and Kerberos. Using=20
PKINIT, a user can authenticate to the KDC via a public key certificate. =
=20
A ticket granting ticket (TGT), returned by the KDC, enables a PK user=20
to obtain tickets and authenticate to kerberized services. The PKDA=20
=0C
proposal goes a step further. It supports direct client to server=20
authentication, eliminating the need for an online key distribution=20
center. In this draft, we describe how, without any modification, the=20
PKINIT protocol may be applied to achieve the goals of PKDA. For direct=20
client to server authentication, the client will use PKINIT to=20
authenticate to the end server (instead of a central KDC), which then,=20
will issue a ticket for itself. The benefit of this proposal, is that a=20
single PK extension to Kerberos can address the goals of PKINIT and=20
PKDA.
3. PKDA background
PKDA is based upon concepts first introduced in [5]. The PKDA proposal=20
provides direct client to server authentication, thus eliminating the=20
need for an online key distribution center. A client and server take=20
part in an initial PK based authentication exchange, with an added
caveat that the server acts as a Kerberos ticket granting service and
issues a traditional Kerberos ticket for itself. In subsequent
communication, the client makes use of the Kerberos ticket, thus
eliminating the need for public key operations on the server. This
approach has an advantage over SSL in that the server does not need to
save state (cache session keys). Furthermore, an additional benefit,
is that Kerberos tickets can facilitate delegation (see [3]).=20
Below is a brief overview of the PKDA protocol. For a more detailed=20
description see [1].=20
SCERT_REQ: Client -> Server
The client requests a certificate from the server. If the server=92s=20
certificate is cached locally, SCERT_REQ and SCERT_REP are omitted.
SCERT_REP: Server -> Client
The server returns its certificate to the client.
PKTGS_REQ: Client -> Server
The client sends a request for a service ticket to the server. To=20
authenticate the request, the client signs, among other fields, a time=20
stamp and a newly generated symmetric key. The time stamp is used to=20
foil replay attacks; the symmetric key is used by the server to secure=20
the PKTGS_REP message.=20
The client provides a certificate in the request (the certificate=20
enables the server to verify the validity of the client=92s signature) an=
d=20
seals it along with the signed information using the server=92s public=20
key. =20
=20
PKTGS_REP: Server -> Client
The server returns a service ticket (which it issued for itself) along=20
with the session key for the ticket. The session key is protected by=20
the client-generated key from the PKTGS_REQ message. =20
AP_REQ: Client -> Server
After the above exchange, the client can proceed in a normal fashion,=20
using the conventional Kerberos ticket in an AP_REQ message.
=0C
4. PKINIT background
One of the principal goals of PKINIT is to provide for interoperability=20
between a public key infrastructure and Kerberos. Using a public key=20
certificate, a client can authenticate to the KDC and receive a TGT=20
which enables the client to obtain service tickets to kerberized=20
services. In PKINIT, the AS-REQ and AS-REP messages remain the same;=20
new preauthentication data types are used to conduct the PK exchange. =20
Client and server certificates are exchanged via the preauthentication=20
data. Thus, the exchange of certificates, PK authentication, and=20
delivery of a TGT can occur in two messages.
Below is a brief overview of the PKINIT protocol. For a more detailed=20
description see [2].=20
PreAuthentication data of AS-REQ: Client -> Server
The client sends a list of trusted certifiers, a signed PK=20
authenticator, and its certificate. The PK authenticator, based on the=20
Kerberos authenticator, contains the name of the KDC, a timestamp, and a=20
nonce.
PreAuthentication data of AS-REP: Server -> Client
The server responds with its certificate and the key used for decrypting=20
the encrypted part of the AS-REQ. This key is encrypted with the=20
client=92s public key.
AP_REQ: Client -> Server
After the above exchange, the client can proceed in a normal fashion,=20
using the conventional Kerberos ticket in an AP_REQ message.
5. Application of PKINIT to achieve equivalence to PKDA
While PKINIT is normally used to retrieve a TGT, it may also be used to
request an end service ticket. When used in this fashion, PKINIT is
functionally equivalent to PKDA. We introduce the concept of a local
ticket granting server (LTGS) to illustrate how PKINIT may be used for
issuing end service tickets based on public key authentication. It is
important to note that the LTGS may be built into an application server,
or it may be a stand-alone server used for issuing tickets within a
well-defined realm, such as a single machine. We will discuss both of
these options.
5.1. The LTGS
The LTGS processes the Kerberos AS-REQ and AS-REP messages with PKINIT=20
preauthentication data. When a client submits an AS-REQ to the LTGS, it=20
specifies an application server in order to receive an end service=20
ticket instead of a TGT.
5.1.1. The LTGS as a standalone server
The LTGS may run as a separate process that serves applications which=20
reside on the same machine. This consolidates administrative functions
and provide an easier migration path for a heterogeneous environment
consisting of both public key and Kerberos. The LTGS would use one
=0C
well-known port (port #88 - same as the KDC) for all message traffic
and would share a symmetric key with each service. After the client=20
receives a service ticket, it contacts the application server=20
directly. This approach is similar to the one suggested by Sirbu, et=20
al [1].
5.1.2. The LTGS as part of an application server
The LTGS may be combined with an application server. This accomplishes=20
direct client to application server authentication; however, it requires=20
that applications be modified to process AS-REQ and AS-REP messages. =20
The LTGS would communicate over the port assigned to the application=20
server or over the well known Kerberos port for that particular=20
application.
6. Protocol differences between PKINIT and PKDA
Both PKINIT and PKDA will accomplish the same goal of issuing end=20
service tickets, based on initial public key authentication. A PKINIT-
based implementation and a PKDA implementation would be functionally=20
equivalent. The primary differences are that 1)PKDA requires the client=20
to create the symmetric key while PKINIT requires the server to create=20
the key and 2)PKINIT accomplishes in two messages what PKDA accomplishes=20
in four messages.
7. Discussion
The concept of Kerberos names (i.e. domain based names) is orthogonal to=20
the concept of public key names, in that X.500 distinguished names do=20
not reside within a particular realm. The assumption is that all user=20
principals will use X.500 distinguished names and that PKINIT will=20
support both X.500 and Kerberos names for application servers. However,=20
it is our recommendation that X.500 be the default naming convention for
application servers.
8. Summary
The PKINIT protocol can be used, without modification, to facilitate=20
client to server authentication without the use of a central KDC. The=20
approach described in this draft (and originally proposed in PKDA[1])=20
is essentially a public key authentication protocol which retains the=20
advantages of Kerberos tickets.
Given that PKINIT has progressed through the CAT working group of the=20
IETF, with plans for non-commercial distribution (via MIT=92s v5 Kerberos=
) =20
as well as plans for commercial support, it is worthwhile to provide
PKDA functionality under the PKINIT umbrella.
9. Bibliography
[1] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using=20
Public Key Cryptography. Symposium On Network and Distributed System=20
Security, 1997.
=0C
[2] B.C. Neuman, B. Tung, J. Wray, . Trostle. Public Key Cryptography=20
for Initial Authentication in Kerberos. Internet Draft, October 1996.=20
(ftp://ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-02.txt)
[3] B.C. Neuman, Proxy-Based Authorization and Accounting for=20
Distributed Systems. In Proceedings of the 13th International=20
Conference on Distributed Computing Systems, May 1993
[4] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
for Computer Networks, IEEE Communications, 32(9):33-38.
September 1994.
[5] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction=20
Protocol. In Proceedings of the USENIX Workshop on Electronic Commerce,
July 1995.
Authors' Addresses
Ari Medvinsky <ari.medvinsky at cybersafe.com>
Matthew Hur <matt.hur at cybersafe.com>
CyberSafe Corporation=20
1605 NW Sammamish Road
Suite 310
Issaquah, WA 98027-5378
Phone: (206) 391-6000
Fax: (206) 391-0508
http:/www.cybersafe.com
B. Clifford Neuman
USC Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey CA 90292-6695
Phone: +1 310 822 1511
E-mail: bcn at isi.edu
=0C
Received: from ietf.org by ietf.org id aa24722; 4 Mar 97 16:21 EST
Received: from ietf.ietf.org by ietf.org id aa23835; 4 Mar 97 16:08 EST
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: SMTP Service Extension for Command Pipelining to Draft
Standard
Reply-to: iesg at ietf.org
Date: Tue, 04 Mar 1997 16:08:49 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703041608.aa23835 at ietf.org>
The IESG has received a request to consider SMTP Service Extension for
Command Pipelining <draft-freed-smtp-pipeline-01.txt> as a Draft
Standard. This document updates RFC1854, currently a Proposed
Standard. This has been reviewed in the IETF but is not the product of
an IETF Working Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by April 3, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa04425; 4 Mar 97 17:54 EST
Received: from cnri by ietf.org id aa03991; 4 Mar 97 17:50 EST
Received: from ginger.lcs.mit.edu by CNRI.Reston.VA.US id aa20562;
4 Mar 97 17:50 EST
Received: by ginger.lcs.mit.edu
id AA24731; Tue, 4 Mar 97 17:38:18 -0500
Date: Tue, 4 Mar 97 17:38:18 -0500
Sender:ietf-request at ietf.org
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9703042238.AA24731 at ginger.lcs.mit.edu>
To: Valdis.Kletnieks at vt.edu, jdjones at sprynet.com
Subject: Re: firewalls
Cc: ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
Source-Info: From (or Sender) name not authenticated.
From: Valdis.Kletnieks at vt.edu
Unfortunately, I work in a university environment, where there's a lot of
machines in departments that don't have a clue. And it's politically
impossible to require proof of clue ownership ... before letting users on
the net....
No doubt they don't bother to keep backups either - typical for this grade
of user.
Just think of the whole situation as evolution in action...
Noel
Received: from ietf.org by ietf.org id aa07174; 4 Mar 97 18:02 EST
Received: from cnri by ietf.org id aa06593; 4 Mar 97 18:01 EST
Received: from black-ice.cc.vt.edu by CNRI.Reston.VA.US id aa20880;
4 Mar 97 18:01 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id RAA21064;
Tue, 4 Mar 1997 17:58:49 -0500
Message-Id: <199703042258.RAA21064 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: jdjones at sprynet.com, ietf at CNRI.Reston.VA.US
Subject: Re: firewalls
In-Reply-To: Your message of "Tue, 04 Mar 1997 17:38:18 EST."
<9703042238.AA24731 at ginger.lcs.mit.edu>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <9703042238.AA24731 at ginger.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-1313945564P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 04 Mar 1997 17:58:44 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-1313945564P
Content-Type: text/plain; charset=us-ascii
On Tue, 04 Mar 1997 17:38:18 EST, Noel Chiappa said:
> No doubt they don't bother to keep backups either - typical for this grade
> of user.
>
> Just think of the whole situation as evolution in action...
I can think of at least one case where I got over to campus, only to
find out that the machine in question:
a) Had no tape drive (and thus no backups)
b) No bootable disk remaining
c) No CD-ROM or floppy to boot an emergency system from
d) A Very Important Professor's Very Important Work on it.
Tenured professors - only way to get rid of them is to induce a heart
attack. Didn't suceeed in this case though ;)
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_-1313945564P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMxypHdQBOOoptg9JAQG7nAP5AVmDbPI326IrB1hS00k6eajhVQ+24DIY
Gsq8WT3HOtfA4J8Sitd4xSJSI6ikTaXfD6PV0uRYtPk6AsTF/kuNwXDAFALiEixN
CHaiiujtDyhMKYkdQlUYAU/ZIijefqtyApeUGw00uK+OYQDG0CKWyLx7t/OEeK9c
8DzakzKqCY0=
=8tob
-----END PGP MESSAGE-----
--==_Exmh_-1313945564P--
Received: from ietf.org by ietf.org id aa08568; 5 Mar 97 8:31 EST
Received: from cnri by ietf.org id aa07613; 5 Mar 97 8:08 EST
Received: from soleil.uvsq.fr by CNRI.Reston.VA.US id aa06710; 5 Mar 97 8:08 EST
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id OAA17532
; Wed, 5 Mar 1997 14:04:32 +0100 (MET)
Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id NAA01995
for <congres at prism.uvsq.fr>; Wed, 5 Mar 1997 13:49:07 +0100 (MET)
Received: from mailer1.lut.ac.uk (mailhost.lut.ac.uk [158.125.1.202])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with SMTP id NAA16949
for <congres at prism.uvsq.fr>; Wed, 5 Mar 1997 13:48:58 +0100 (MET)
Received: from sun-cc201.lboro.ac.uk [158.125.1.201] (root)
by mailer1.lut.ac.uk with smtp (Exim 1.596 #1)
id 0w2G7k-0000D2-00; Wed, 5 Mar 1997 12:48:48 +0000
Received: from [194.66.220.37] [194.66.220.37]
by sun-cc201.lboro.ac.uk with smtp (Exim 1.596 #1)
id 0w2G7h-00019Z-00; Wed, 5 Mar 1997 12:48:45 +0000
X-Sender: acno at hpcin.lboro.ac.uk
Message-Id: <v01510101af431c26e83b at [194.66.220.37]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: congres at prism.uvsq.fr
Sender:ietf-request at ietf.org
From: Niall O'Loughlin <N.Oloughlin at lcad.ac.uk>
Subject: 21N97
Date: Wed, 5 Mar 1997 12:48:45 +0000
Source-Info: From (or Sender) name not authenticated.
I have just received part of a message about a call for papers but the
important part is missing. Would you send the message again, please?
Regards,
Niall O'Loughlin
Dr Niall O'Loughlin
Loughborough College of Art and Design
Epinal Way, Loughborough, Leicestershire
LE11 3GE U.K.
Telephone 01509-261515 ext 176
International +44-1509-261515 ext 176
Fax 01509-265515
International +44-1509-265515
e-mail: N.Oloughlin at lcad.ac.uk
Received: from ietf.org by ietf.org id aa11859; 5 Mar 97 9:38 EST
Received: from ietf.ietf.org by ietf.org id aa11649; 5 Mar 97 9:32 EST
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-newman-url-imap-06.txt
Date: Wed, 05 Mar 1997 09:32:52 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703050932.aa11649 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Note: This revision reflects comments received during the last call period.
Title : IMAP URL Scheme
Author(s) : C. Newman
Filename : draft-newman-url-imap-06.txt
Pages : 10
Date : 03/04/1997
IMAP [IMAP4] is a rich protocol for accessing remote message stores. It
provides an ideal mechanism for accessing public mailing list archives as
well as private and shared message stores. This document defines a URL
scheme for referencing objects on an IMAP server.
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-newman-url-imap-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-newman-url-imap-06.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-newman-url-imap-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.
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: <19970304135937.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-newman-url-imap-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-newman-url-imap-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970304135937.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12308; 5 Mar 97 9:45 EST
Received: from ietf.ietf.org by ietf.org id aa11686; 5 Mar 97 9:33 EST
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-iwps-schema-spec-04.txt
Date: Wed, 05 Mar 1997 09:33:03 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703050933.aa11686 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.
Note: This revision reflects comments received during the last call period.
Title : A Common Schema for the Internet White Pages Service
Author(s) : T. Genovese, B. Jennings
Filename : draft-ietf-ids-iwps-schema-spec-04.txt
Pages : 6
Date : 03/04/1997
The work is the result of the IETF Integrated Directory Services (IDS)
Working Group which proposes to establish a specification for a simple
Internet white pages service. To facilitate this effort it would be
helpful to have a common schema used by the various white page servers.
This document is designed to specify the basic set of attributes to be used
for a white page entry for an individual. It describes how new objects can
be defined and registered. This schema is independent of specific
implementations of the White Page service.
This document does not describe how to represent other objects in the
White page service. Further it does not address the search/sort
expectations within a particular service.
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-iwps-schema-spec-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ids-iwps-schema-spec-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-ids-iwps-schema-spec-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.
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: <19970305092913.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ids-iwps-schema-spec-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ids-iwps-schema-spec-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305092913.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12309; 5 Mar 97 9:45 EST
Received: from ietf.ietf.org by ietf.org id aa11632; 5 Mar 97 9:32 EST
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-sanghi-pmtudisc-ext-00.txt
Date: Wed, 05 Mar 1997 09:32:48 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703050932.aa11632 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Extended Path MTU Discovery for IP version 6
Author(s) : D. Sanghi, S. Shah
Filename : draft-sanghi-pmtudisc-ext-00.txt
Pages : 6
Date : 03/04/1997
This draft discusses extensions to the present Path MTU Discovery mechanism
[PMTUDISC]. It provides applications finer control over the delay and
losses incurred during the PMTU Discovery process. The document proposes
two extension header options that allow PMTU Discovery with minimal
overheads.
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-sanghi-pmtudisc-ext-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-sanghi-pmtudisc-ext-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-sanghi-pmtudisc-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.
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: <19970304115840.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-sanghi-pmtudisc-ext-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-sanghi-pmtudisc-ext-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970304115840.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12311; 5 Mar 97 9:45 EST
Received: from ietf.ietf.org by ietf.org id aa11668; 5 Mar 97 9:32 EST
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-lantz-00.txt
Date: Wed, 05 Mar 1997 09:32:57 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703050932.aa11668 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Usage of H.323 on the Internet
Author(s) : P. Lantz
Filename : draft-rfced-info-lantz-00.txt
Pages : 16
Date : 03/04/1997
The H.323 standard defined by the International Telecommunication Union
(ITU) describes "Visual telephone systems and equipment for local area
networks which provide a non-guaranteed quality of service", that is to
say, video conferencing over Local Area Networks and the Internet.
Although it has been generally accepted that H.323 is an appropriate
standard for audio/video telephony on the Internet, it is a complex
standard. It describes a broad and complex set of capabilities, including
interoperation with other types of video conferencing systems, and contains
references to a number of other ITU standards.
This document describes the parts of the standard that are necessary
for Internet telephony and multipoint conferencing. It describes the
messages that are necessary to work with other H.323 implementations.
In a separate section, it also lists the messages that must be implemented
to be H.323 compliant.
This document is a guide to make the standard more accessible. It is not
intended to duplicate information in the standard. It does not contain
specifications of the messages or details of the protocol.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-rfced-info-lantz-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-lantz-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-rfced-info-lantz-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: <19970304144548.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-lantz-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-lantz-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970304144548.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa25739; 5 Mar 97 13:07 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12264;
5 Mar 97 13:07 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <PAA15298 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 15:46:47 GMT
Message-Id: <9703051543.AA17771 at us1rmc.bb.dec.com>
Date: Wed, 5 Mar 97 10:43:00 EST
From: "John Wray, Digital DPE, (508) 486-5210 05-Mar-1997 1032" <wray at tuxedo.enet.dec.com>
To: "cat-ietf at mit.edu"@in.enet.dec.com
Cc: wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu
Subject: gss_export_sec_context()
Precedence: bulk
In my (hopefully) final cleanup pass over the GSSAPI C-bindings, I noticed an
ambiguity with gss_export_sec_context(). This routine takes a context handle
(identifying the context to be exported), and returns an interprocess token in
a buffer for the application to pass to another process.
The routine description says that, on return from this routine, the context
identified by the context handle can no longer be accessed by the calling
process.
i) What happens to the context if the routine fails for some reason (maybe the
implementation doesn't support transferrable contexts)? Should the input
context still be made inaccessible?
ii) Do we really want a successful call to make the context totally
inaccessible? In particular, should this routine delete all process-wide
resources associated with the original context, or should that responsibility
lie with the application (in which case the context isn't totally inaccessible,
but can only be accessed by the application to delete it)?
John
Received: from cnri by ietf.org id aa27184; 5 Mar 97 13:59 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13129;
5 Mar 97 13:59 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <QAA17261 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 16:34:21 GMT
Message-Id: <9703051624.AA21675 at us1rmc.bb.dec.com>
Date: Wed, 5 Mar 97 11:24:18 EST
From: "John Wray, Digital DPE, (508) 486-5210 05-Mar-1997 1105" <wray at tuxedo.enet.dec.com>
To: "cat-ietf at mit.edu"@in.enet.dec.com
Cc: wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu
Subject: OIDs and OID sets (again)
Precedence: bulk
I think we still have a minor problem with dynamic vs. static OIDs & OID sets.
The consensus from the San Jose meeting was that we should remove the str<->oid
functions from the GSSAPI spec with the purpose of making all GSSAPI-created
OIDs static (non-freeable), and we subsequently seem to have reached agreement
that OID-sets should be dynamically allocated (i.e. the application must call
gss_release_oid_set() to free them).
How about the OID elements within a OID-set? Since OIDs are put into OID-sets
by gss_add_oid_set_member(), this routine has two options: it can either put a
pointer to the existing OID into the set, or create a heap-allocated copy of
the OID (which would then be deallocated with gss_release_oid_set()). The
first method means that an application must make sure that any OID that it puts
into an OID-set stays around for at least as long as the OID-set, whereas the
second method makes the OID-set a self-contained object.
I don't think there are any backwards-compatibilty problems with either
solution, since the V1 spec didn't provide the add_oid_set_member function, and
therefore OID-sets could be implemented either way transparently to the
application. Now we've provided a way for apps to generate OID-sets containing
their own OID values, we have to pick a particualr storage model.
I prefer the second method, where the OIDs within a set are "owned" by the set,
and are freed by gss_release_oid_set(). Mixing application-managed and
GSSAPI-managed storage within a single data structure seems to be asking for
memory-leaks.
John
Received: from cnri by ietf.org id aa29406; 5 Mar 97 15:20 EST
Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa14671;
5 Mar 97 15:20 EST
Received: (from daemon at localhost) by external.BSDI.COM (8.8.5/8.8.2) id NAA02107 for telnet-ietf-list at bsdi.com; Wed, 5 Mar 1997 13:15:25 -0700 (MST)
Received: from deis38.deis.unibo.it. (deis38.deis.unibo.it [137.204.57.38]) by external.BSDI.COM (8.8.5/8.8.2) with SMTP id NAA02096 for <telnet-ietf at bsdi.com>; Wed, 5 Mar 1997 13:15:19 -0700 (MST)
Received: by deis38.deis.unibo.it. (SMI-8.6/SMI-SVR4)
id VAA17832; Wed, 5 Mar 1997 21:18:12 +0100
Date: Wed, 5 Mar 1997 21:18:12 +0100
From: Sebastien Boving <seb at deis38.deis.unibo.it>
Message-Id: <199703052018.VAA17832 at deis38.deis.unibo.it.>
To: telnet-ietf at bsdi.com
Subject: encrypting 1 char at a time?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: qmmEoca5JxhruJD4pynTlA==
Hi *,
As you might remember i'm working on telnet to make it work with SESAME
authentication/encryption.
I just finished the authentication part (BTW, i had to make some changes
to auth_wait(), i guess the AUTH_VALID option with automatic login wasn't
completed implemented?), and will attack the encryption part one
of these days.
Before i start, i'd like to have your advice on a few things:
- Except for the kludge linemode (LINEMODE option is not supported for Solaris),
telnet sends one char at the time from client to server. Encrypting one
char is not very secure since an attacker could recognize some of them
quite easily (i mean the 'j' would always be enciphered the same way, and
'j' f.i. is also repeatedly used in elm, vi, etc...). Changing the session
key after every char brings too much overhead, so except working in the
kludged linemode, what can i do? How do other encryption software do this?
- Implementing authentication was quite easy since the source contained
some examples (especially SPX, since it also works with a GSS-API). The main
problem was making the underlying security mechanism (SESAME) working and
configuring it. For implementing the encryption, the only practical document
i have is the internet-draft on the AUTH_ENCRYPT option (though this option
will not be added). Are there any other interesting documents i should be
aware of? (Especially modified telnet source for other security mechanisms
would be welcome).
TIA,
Sebastien Boving.
Received: from cnri by ietf.org id aa29623; 5 Mar 97 15:29 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14812;
5 Mar 97 15:29 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA20689 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 17:55:52 GMT
From: Jacques Lebastard <J.Lebastard at frcl.bull.fr>
Message-Id: <9703051747.AA16193 at ronde.frcl.bull.fr>
Subject: Re: gss_export_sec_context()
To: John Wray Digital DPE <wray at tuxedo.enet.dec.com>
Date: Wed, 5 Mar 1997 18:47:42 +0100 ("MET)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703051543.AA17771 at us1rmc.bb.dec.com> from "John Wray, Digital DPE," at Mar 5, 97 10:43:00 am
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Precedence: bulk
> i) What happens to the context if the routine fails for some reason (maybe the
> implementation doesn't support transferrable contexts)? Should the input
> context still be made inaccessible?
In such a case, the context should not be modified at all and therefore
accessible to all GSS routines.
> ii) Do we really want a successful call to make the context totally
> inaccessible? In particular, should this routine delete all process-wide
> resources associated with the original context, or should that responsibility
> lie with the application (in which case the context isn't totally
> inaccessible, but can only be accessed by the application to delete it)?
I'd recommend the application to invoke gss_delete_sec_context to actually
delete the context.
--
Jacques LEBASTARD mailto:J.Lebastard at frcl.bull.fr
BULL SA - ISM AccessMaster http://www-ism.bull.com/ism/
Rue Jean Jaures - A5/146 Tel: +33 (0)1 30 80 77 86
F-78340 Les Clayes sous Bois Fax: +33 (0)1 30 80 77 99
Received: from cnri by ietf.org id aa00396; 5 Mar 97 16:07 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15475;
5 Mar 97 16:07 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA24612 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 19:23:01 GMT
Date: Wed, 5 Mar 1997 14:22:56 -0500
Message-Id: <9703051922.AA06547 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: cat-ietf at mit.edu
Subject: Re: OIDs and OID sets (again)
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Wed, 5 Mar 97 11:24:18 EST
From: "John Wray, Digital DPE, (508) 486-5210 05-Mar-1997 1105" <wray at tuxedo.ENET.dec.com>
How about the OID elements within a OID-set? Since OIDs are put into
OID-sets by gss_add_oid_set_member(), this routine has two options:
it can either put a pointer to the existing OID into the set, or
create a heap-allocated copy of the OID (which would then be
deallocated with gss_release_oid_set()). The first method means that
an application must make sure that any OID that it puts into an
OID-set stays around for at least as long as the OID-set, whereas the
second method makes the OID-set a self-contained object.
I believe the OID-set should be a self-contained object. The problems
associated with pointer aliasing are too horrible to contemplate. It's
not just memory leaks; it's also the side effects when you modify an OID
that's being pointed to by the OID-set.
- Ted
Received: from cnri by ietf.org id aa01611; 5 Mar 97 16:41 EST
Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa16144;
5 Mar 97 16:41 EST
Received: (from daemon at localhost) by external.BSDI.COM (8.8.5/8.8.2) id OAA10528 for telnet-ietf-list at bsdi.com; Wed, 5 Mar 1997 14:38:48 -0700 (MST)
Received: from forge.BSDI.COM (dab at forge.BSDI.COM [205.230.224.24]) by external.BSDI.COM (8.8.5/8.8.2) with ESMTP id OAA10514; Wed, 5 Mar 1997 14:38:32 -0700 (MST)
Received: (from dab at localhost) by forge.BSDI.COM (8.8.2/8.7.3) id OAA02645; Wed, 5 Mar 1997 14:38:31 -0700 (MST)
Date: Wed, 5 Mar 1997 14:38:31 -0700 (MST)
From: David Borman <dab at bsdi.com>
Message-Id: <199703052138.OAA02645 at forge.BSDI.COM>
To: seb at deis38.deis.unibo.it, telnet-ietf at bsdi.com
Subject: Re: encrypting 1 char at a time?
Sebastien,
> - Except for the kludge linemode (LINEMODE option is not supported for Solaris),
> telnet sends one char at the time from client to server. Encrypting one
> char is not very secure since an attacker could recognize some of them
> quite easily (i mean the 'j' would always be enciphered the same way, and
> 'j' f.i. is also repeatedly used in elm, vi, etc...). Changing the session
> key after every char brings too much overhead, so except working in the
> kludged linemode, what can i do? How do other encryption software do this?
You don't directly encrypt the data. You use key to encrypt a some known
text, and then feed the output back into the encryption engine. The
resulting stream is then XORed with the clear text to generate the
encrypted data. The receiver knows the same key and initial data,
generates the same stream of numbers, and XORes it with the encrypted
data to generate the clear text. This is called Output Feedback. If
you feed back in the encrypted data stream, then you have Cipher Feedback.
The latter is usually the prefered method.
For example, here are pictures showing cipher feedback:
Encryption:
Clear Text Data --------------+
|
+------------+ |
Key -----> | Encryption | v
Initial vector -> +-> | Engine |---> XOR --> Encrypted Data
| +------------+ |
+-----------------------+
Decryption:
Encrypted Data ------------+-----+
| |
+------------+ | |
Key -----> | Encryption | | v
Initial vector -> +-> | Engine |---(--> XOR --> Clear Text Data
| +------------+ |
+--------------------+
> - Implementing authentication was quite easy since the source contained
> some examples (especially SPX, since it also works with a GSS-API). The main
> problem was making the underlying security mechanism (SESAME) working and
> configuring it. For implementing the encryption, the only practical document
> i have is the internet-draft on the AUTH_ENCRYPT option (though this option
> will not be added). Are there any other interesting documents i should be
> aware of? (Especially modified telnet source for other security mechanisms
> would be welcome).
ftp://ftp.cray.com/src/telnet/telnet.rfc.tar.Z
is a collection of Telnet related RFCs, including the draft of
the encryption option from March, 1992, with documentation of
DES cipher and output feedback.
> TIA,
> Sebastien Boving.
-David Borman, dab at bsdi.com
Received: from cnri by ietf.org id aa02062; 5 Mar 97 16:57 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16487;
5 Mar 97 16:57 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA20801 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 17:59:19 GMT
Message-Id: <199703051758.AA29340 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: John Wray Digital DPE <wray at tuxedo.enet.dec.com>
Date: Wed, 5 Mar 1997 12:58:22 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703051543.AA17771 at us1rmc.bb.dec.com> from "John Wray, Digital DPE," at Mar 5, 97 10:43:00 am
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Wray, Digital DPE, wrote:
> In my (hopefully) final cleanup pass over the GSSAPI C-bindings, I noticed an
> ambiguity with gss_export_sec_context(). This routine takes a context handle
> (identifying the context to be exported), and returns an interprocess token in
> a buffer for the application to pass to another process.
>
> The routine description says that, on return from this routine, the context
> identified by the context handle can no longer be accessed by the calling
> process.
>
> i) What happens to the context if the routine fails for some reason (maybe the
> implementation doesn't support transferrable contexts)? Should the input
> context still be made inaccessible?
I'd like to see "transaction integrity": either context export works
successfully, or an error will be returned and the context will remain
completely unchanged.
>
> ii) Do we really want a successful call to make the context totally
> inaccessible? In particular, should this routine delete all process-wide
> resources associated with the original context, or should that responsibility
> lie with the application (in which case the context isn't totally inaccessible,
> but can only be accessed by the application to delete it)?
Upon successful return (GSS_S_COMPLETE), the context should no longer exist
in memory and the context_handle is to be cleared by the gssapi mechanism.
When the routine returns anthing else than GSS_S_COMPLETE, the context
should not have changed in any way, and the handle must remain untouched.
The equivalent of delete_sec_context() should be called as the very last
action of export_context(). If creating the interprocess_token in a
standalone gss_buffer_t object is successful, then export_context should
return GSS_S_COMPLETE and clear the context handle, even when there is
some awkward problem during delete_sec_context() (which should be impossible
at this point).
-Martin
Received: from cnri by ietf.org id aa02090; 5 Mar 97 16:58 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16500;
5 Mar 97 16:58 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA28124 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 20:36:43 GMT
To: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
Subject: Re: OIDs and OID sets (again)
References: <9703051624.AA21675 at us1rmc.bb.dec.com>
From: Marc Horowitz <marc at cygnus.com>
Date: 05 Mar 1997 15:36:41 -0500
In-Reply-To: "John Wray, Digital DPE,'s message of Wed, 5 Mar 97 11:24:18 EST
Message-Id: <t53lo82vzxi.fsf at rover.cygnus.com>
Lines: 15
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
"John Wray, Digital DPE, (508) 486-5210 05-Mar-1997 1105" <wray at tuxedo.ENET.dec.com> writes:
>> I prefer the second method, where the OIDs within a set are "owned"
>> by the set, and are freed by gss_release_oid_set(). Mixing
>> application-managed and GSSAPI-managed storage within a single data
>> structure seems to be asking for memory-leaks.
This seems obvious. I didn't even consider an implementor misguided
enough to believe that maintaining pointers to the
application-provided oid was reasonable.
Marc
P.S. John, is Digital *ever* going to fix your mailer's outgoing
headers, or should I just give up?
Received: from cnri by ietf.org id aa02503; 5 Mar 97 17:15 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16887;
5 Mar 97 17:15 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA24662 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 19:23:26 GMT
Date: Wed, 5 Mar 1997 14:23:21 -0500
Message-Id: <9703051923.AA06550 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: cat-ietf at mit.edu
Subject: Re: gss_export_sec_context()
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Wed, 5 Mar 97 10:43:00 EST
From: "John Wray, Digital DPE, (508) 486-5210 05-Mar-1997 1032" <wray at tuxedo.enet.dec.com>
i) What happens to the context if the routine fails for some reason
(maybe the implementation doesn't support transferrable contexts)?
Should the input context still be made inaccessible?
No; in general, API calls should atomically fail (i.e., if they fail,
they should do nothing.)
ii) Do we really want a successful call to make the context totally
inaccessible? In particular, should this routine delete all
process-wide resources associated with the original context, or
should that responsibility lie with the application (in which case
the context isn't totally inaccessible, but can only be accessed by
the application to delete it)?
Yes, we have to make it totally inaccessible. In particular, services
such as sequencing and reply protection are not well defined if we don't
do this. And it does have to delete all of the process-side resources
associated with the context handle, because the application *can't* do
it; the only way to access the resources associated to the context
handle is via GSSAPI library.
- Ted
Received: from cnri by ietf.org id aa03398; 5 Mar 97 17:48 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17343;
5 Mar 97 17:48 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA26641 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 20:00:11 GMT
Message-Id: <199703051940.AA07350 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: OIDs and OID sets (again)
To: John Wray Digital DPE <wray at tuxedo.enet.dec.com>
Date: Wed, 5 Mar 1997 14:41:17 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703051624.AA21675 at us1rmc.bb.dec.com> from "John Wray, Digital DPE," at Mar 5, 97 11:24:18 am
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Wray, Digital DPE, wrote:
> I think we still have a minor problem with dynamic vs. static OIDs & OID sets.
>
> The consensus from the San Jose meeting was that we should remove the str<->oid
> functions from the GSSAPI spec with the purpose of making all GSSAPI-created
> OIDs static (non-freeable), and we subsequently seem to have reached agreement
> that OID-sets should be dynamically allocated (i.e. the application must call
> gss_release_oid_set() to free them).
Actually, this is interesting:
We agreed that the application must call gss_release_oid_set() to RELEASE
them.
We didn't discuss if you are allowed to pass OID_sets to add_oid_set_member
OTHER than those created by create_empty_oid_set and those modified
by add_oid_set_member.
I would object to any application that tries to feed into add_oid_set_member
an OID_set that was returned from any of acquire_cred(), add_cred(),
indicate_mechs(), inquire_cred(), inquire_mechs_for_name and
inquire_names_for_mech(). Otherwise all OID_sets will have to be completely
dynamic, especially the one returned from indicate_mechs.
-Martin
Received: from cnri by ietf.org id aa03880; 5 Mar 97 18:02 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17643;
5 Mar 97 18:02 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA22345 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 18:34:25 GMT
Message-Id: <9703051825.AA01544 at us1rmc.bb.dec.com>
Date: Wed, 5 Mar 97 13:25:12 EST
From: "John Wray, Digital DPE, (508) 486-5210 05-Mar-1997 1315" <wray at tuxedo.enet.dec.com>
To: j.lebastard at frcl.bull.fr
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at MIT.EDU, j.lebastard at frcl.bull.fr
Subject: Re: gss_export_sec_context()
Precedence: bulk
>> i) What happens to the context if the routine fails for some reason (maybe the
>> implementation doesn't support transferrable contexts)? Should the input
>> context still be made inaccessible?
>
>In such a case, the context should not be modified at all and therefore
>accessible to all GSS routines.
That was my first thought, but for the application to be able to know what's
happened, I think this means that the GSSAPI implementation will have to
guarantee that in the event of any error, the input context will be untouched
(and therefore still valid). If that's not too onerous on GSSAPI implementors,
I'm happy with this.
>> ii) Do we really want a successful call to make the context totally
>> inaccessible? In particular, should this routine delete all process-wide
>> resources associated with the original context, or should that responsibility
>> lie with the application (in which case the context isn't totally
>> inaccessible, but can only be accessed by the application to delete it)?
>
>I'd recommend the application to invoke gss_delete_sec_context to actually
>delete the context.
There are two problems with this:
i) If the application provides a token buffer to delete_sec_context, gets a
token back, and transmits it to the peer, then the peer will presumably
delete its half of the context, so the transferred context won't work.
Now, this is an application bug, but if export_sec_context were to do the
local deletion, then it wouldn't be a possibility.
ii) I can conceive of some implementations actually maintaining context
information internally, in shared memory, and using the token simply
as a handle to this internal global state. In such an implementation,
"making the context inaccessible to a process" might not be quite the
same as "deleting the context" from that process, since in the first
case you'd want the actual context data to stay around for the import
operation, whereas in the second case you'd want the GSSAPI
implementation to actually free the resources.
John
Received: from cnri by ietf.org id aa03887; 5 Mar 97 18:02 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17653;
5 Mar 97 18:02 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA28012 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 20:33:04 GMT
To: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
Subject: Re: gss_export_sec_context()
References: <9703051543.AA17771 at us1rmc.bb.dec.com>
From: Marc Horowitz <marc at cygnus.com>
Date: 05 Mar 1997 15:32:44 -0500
In-Reply-To: "John Wray, Digital DPE,'s message of Wed, 5 Mar 97 10:43:00 EST
Message-Id: <t53n2siw043.fsf at rover.cygnus.com>
Lines: 29
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
"John Wray, Digital DPE, (508) 486-5210 05-Mar-1997 1032" <wray at tuxedo.enet.dec.com> writes:
>> i) What happens to the context if the routine fails for some reason
>> (maybe the implementation doesn't support transferrable contexts)?
>> Should the input context still be made inaccessible?
I think the context should be made inaccessible. This is clear and
unambiguous. If the implementation doesn't support transferrable
contexts, then there the flags returned from
gss_init/accept_sec_context will indicate this. If there's some other
failure, I can't imagine any kind of sensible recovery process.
If someone has another unambiguous alternative which might support a
different recovery process, I'm interested in hearing it, but I think
KISS applies here.
>> ii) Do we really want a successful call to make the context totally
>> inaccessible? In particular, should this routine delete all
>> process-wide resources associated with the original context, or
>> should that responsibility lie with the application (in which case
>> the context isn't totally inaccessible, but can only be accessed by
>> the application to delete it)?
Yes, as a side effect, the all resources associated with the context
handle should be deleted. It would seem to require extra complexity
in the GSSAPI and the application to have a special deletable-only
context, so there's no good reason to do this.
Marc
Received: from cnri by ietf.org id aa04278; 5 Mar 97 18:19 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17960;
5 Mar 97 18:19 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA23027 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 18:48:12 GMT
Message-Id: <9703051834.AA02229 at us1rmc.bb.dec.com>
Date: Wed, 5 Mar 97 13:34:47 EST
From: "John Wray, Digital DPE, (508) 486-5210 05-Mar-1997 1326" <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: gss_export_sec_context()
Precedence: bulk
>John Wray, Digital DPE, wrote:
>> In my (hopefully) final cleanup pass over the GSSAPI C-bindings, I noticed an
>> ambiguity with gss_export_sec_context(). This routine takes a context handle
>> (identifying the context to be exported), and returns an interprocess token in
>> a buffer for the application to pass to another process.
>>
>> The routine description says that, on return from this routine, the context
>> identified by the context handle can no longer be accessed by the calling
>> process.
>>
>> i) What happens to the context if the routine fails for some reason (maybe the
>> implementation doesn't support transferrable contexts)? Should the input
>> context still be made inaccessible?
>
>I'd like to see "transaction integrity": either context export works
>successfully, or an error will be returned and the context will remain
>completely unchanged.
That means that either the GSSAPI implementation has to verify somehow that the
entire operation is going to succeed before it performs it, or that it provide
some way to roll-back in the event of an error (in practice, it'd probably
require a combination of these techniques). The only reason I'm hesitant about
requiring this is that it seems like it might be a lot of work for an
implementation to do.
>>
>> ii) Do we really want a successful call to make the context totally
>> inaccessible? In particular, should this routine delete all process-wide
>> resources associated with the original context, or should that responsibility
>> lie with the application (in which case the context isn't totally inaccessible,
>> but can only be accessed by the application to delete it)?
>
>Upon successful return (GSS_S_COMPLETE), the context should no longer exist
>in memory and the context_handle is to be cleared by the gssapi mechanism.
>
>When the routine returns anthing else than GSS_S_COMPLETE, the context
>should not have changed in any way, and the handle must remain untouched.
OK (with the above reservations concerning implementation complexity).
>The equivalent of delete_sec_context() should be called as the very last
>action of export_context().
With the one proviso that not all the functionality of delete_sec_context() may
be wanted: in particular, if some context-specific state has to be retained in
order for the context to be imported in another process, that state obviously
shouldn't be deleted.
>If creating the interprocess_token in a
>standalone gss_buffer_t object is successful, then export_context should
>return GSS_S_COMPLETE and clear the context handle, even when there is
>some awkward problem during delete_sec_context() (which should be impossible
>at this point).
OK.
John
Received: from cnri by ietf.org id aa04775; 5 Mar 97 18:44 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18322;
5 Mar 97 18:44 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA27657 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 20:25:10 GMT
Message-Id: <199703052023.AA10310 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: Jacques Lebastard <J.Lebastard at frcl.bull.fr>
Date: Wed, 5 Mar 1997 15:24:06 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703051747.AA16193 at ronde.frcl.bull.fr> from "Jacques Lebastard" at Mar 5, 97 06:47:42 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Jacques Lebastard wrote:
> > ii) Do we really want a successful call to make the context totally
> > inaccessible? In particular, should this routine delete all process-wide
> > resources associated with the original context, or should that responsibility
> > lie with the application (in which case the context isn't totally
> > inaccessible, but can only be accessed by the application to delete it)?
>
> I'd recommend the application to invoke gss_delete_sec_context to actually
> delete the context.
Could you be a little more specific why you want to explicitly call
delete_sec_context()?
It's true that RFC2078 says that "the context will be invalid
after export", so it might need to be clarified, but the C-Bindings
and Ted's original proposal pass the context_handle by reference --
so that it can be wiped when the operation succeeds.
An invalid but undeleted context would be totally useless in my
opinion. IMO, a context that is not valid would have to be rejected
by gss_delete_sec_context() with GSS_C_NO_CONTEXT -- if you read the
spec verbatim. ;-)
If the context remained valid after export, further processing
of messages is guaranteed to cause trouble with the features
"Sequencing" and "Replay Detection" for the next context importer.
What do you think an application could want to do with the context_handle
after exporting the context? The only thing available for discussion
is gss_delete_sec_context(). What should it do when this fails?
My application will definitely ignore that; at most I would write some
log that there might be something wrong with the gssapi mechanism
or with the invocation of the call which eventually should be checked.
The application definitely shouldn't abort (once it's shipping).
-Martin
Received: from cnri by ietf.org id aa04981; 5 Mar 97 18:59 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18531;
5 Mar 97 18:59 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA24828 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 19:26:49 GMT
Message-Id: <199703051925.AA06552 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: OIDs and OID sets (again)
Orig-To: wray at tuxedo.ENET.dec.com (John Wray, Digital DPE, )
To: cat-ietf at mit.edu
Date: Wed, 5 Mar 1997 14:25:31 -0500 (EST)
In-Reply-To: <9703051624.AA21675 at us1rmc.bb.dec.com> from "John Wray, Digital DPE," at Mar 5, 97 11:24:18 am
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Wray, Digital DPE, wrote:
>
> I think we still have a minor problem with dynamic vs. static OIDs & OID sets.
>
> The consensus from the San Jose meeting was that we should remove the str<->oid
> functions from the GSSAPI spec with the purpose of making all GSSAPI-created
> OIDs static (non-freeable), and we subsequently seem to have reached agreement
> that OID-sets should be dynamically allocated (i.e. the application must call
> gss_release_oid_set() to free them).
>
> How about the OID elements within a OID-set? Since OIDs are put into OID-sets
> by gss_add_oid_set_member(), this routine has two options: it can either put a
> pointer to the existing OID into the set, or create a heap-allocated copy of
> the OID (which would then be deallocated with gss_release_oid_set()). The
> first method means that an application must make sure that any OID that it puts
> into an OID-set stays around for at least as long as the OID-set, whereas the
> second method makes the OID-set a self-contained object.
To avoid ANY possible problems with different heap allocators, especially
in shared library environments, it is necessary that objects are entirely
managed by one single service provider (library). I.e. oid_sets returned
by a gssapi mechanism have to completely managed and owned by the mechanism.
How a mechanism composes compound objects is a local matter (i.e.
implementation detail outside of the spec). If a mechanism creates oid_sets
that refer to static OID-elements octet strings, then it is responsible to
handle them correctly within gss_release_oid_set.
Glue layers that add up gssapi mechanisms to a multimechanism will have
either have to know about the nature of the oid_sets of the submechanisms,
or they will have to register or clone the oid_sets while they still know
which submechanism created the oid_set, so that it can later be released
correctly.
Passing application defined OID_sets to add_oid_set_member will cause
undefined behaviour -- passing OID of arbitrary nature is ok, since
the OID is a read-only input parameter.
>
> I don't think there are any backwards-compatibilty problems with either
> solution, since the V1 spec didn't provide the add_oid_set_member function, and
> therefore OID-sets could be implemented either way transparently to the
> application. Now we've provided a way for apps to generate OID-sets containing
> their own OID values, we have to pick a particualr storage model.
>
> I prefer the second method, where the OIDs within a set are "owned" by the set,
> and are freed by gss_release_oid_set(). Mixing application-managed and
> GSSAPI-managed storage within a single data structure seems to be asking for
> memory-leaks.
Even worse, it's asking for core dumps / GPVs / big trouble.
ANSI-C uses the term "undefined behaviour".
It should be emphasized in the spec that add_oid_set_member
is only allowed for OID_sets created by create_empty_oid_set().
-Martin
Received: from cnri by ietf.org id aa05078; 5 Mar 97 19:05 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18663;
5 Mar 97 19:05 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA23930 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 19:11:57 GMT
Message-Id: <199703051911.AA05538 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: John Wray Digital DPE <wray at tuxedo.enet.dec.com>
Date: Wed, 5 Mar 1997 14:11:25 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703051834.AA02229 at us1rmc.bb.dec.com> from "John Wray, Digital DPE," at Mar 5, 97 01:34:47 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Wray, Digital DPE, wrote:
> Martin Rex wrote:
> >John Wray wrote:
> >> i) What happens to the context if the routine fails for some reason (maybe the
> >> implementation doesn't support transferrable contexts)? Should the input
> >> context still be made inaccessible?
> >
> >I'd like to see "transaction integrity": either context export works
> >successfully, or an error will be returned and the context will remain
> >completely unchanged.
>
> That means that either the GSSAPI implementation has to verify somehow that the
> entire operation is going to succeed before it performs it, or that it provide
> some way to roll-back in the event of an error (in practice, it'd probably
> require a combination of these techniques). The only reason I'm hesitant about
> requiring this is that it seems like it might be a lot of work for an
> implementation to do.
I think it should be rather easy. Since the exported context is
a standalone flat object and does not share any objects with the
security context, the creation of the exported context does not
harm the security context at all. If you start deleting the context
object only after the creation of the exported context has completed
successfully, then I don't see the problem.
After all, that is exactly what happens if the application called
export_sec_context()/delete_sec_context() in sequence before passing
the exported context along to a different process.
If context transfer is to work at all, it will work if the gssapi
mechanism does the delete within the export.
>
> >>
> >> ii) Do we really want a successful call to make the context totally
> >> inaccessible? In particular, should this routine delete all process-wide
> >> resources associated with the original context, or should that responsibility
> >> lie with the application (in which case the context isn't totally inaccessible,
> >> but can only be accessed by the application to delete it)?
> >
> >Upon successful return (GSS_S_COMPLETE), the context should no longer exist
> >in memory and the context_handle is to be cleared by the gssapi mechanism.
> >
> >When the routine returns anthing else than GSS_S_COMPLETE, the context
> >should not have changed in any way, and the handle must remain untouched.
>
> OK (with the above reservations concerning implementation complexity).
>
> >The equivalent of delete_sec_context() should be called as the very last
> >action of export_context().
>
> With the one proviso that not all the functionality of delete_sec_context() may
> be wanted: in particular, if some context-specific state has to be retained in
> order for the context to be imported in another process, that state obviously
> shouldn't be deleted.
Your last comment frightens me. You should not keep ANY context-specific
state around in the process image of the process that does the export!
(1) It's NOT ok for a gss-api mechanism to leak memory for
context_export/context_import activity.
(2) An application may decide to memset an exported security context to
zero, while the gssapi mechanism must still conform to (1).
(3) A context import may fail with GSS_S_CONTEXT_EXPIRED or other
error codes, in which case an application will probably do (2).
(4) The context-exporting process may exit before the exported context
will be imported by another process.
(I'm going to implement security context caching for specific
client applications that will require this characteristic,
mainly to improve performance for public key based authentication
and to save round trips on the average).
These are rules that we require for successful interoperation with
our application. The requirements may make it hard to impossible
to enforce certain policies on exported security contexts ...
-Martin
Received: from cnri by ietf.org id aa05624; 5 Mar 97 19:34 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19084;
5 Mar 97 19:34 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <XAA04500 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 23:09:41 GMT
Message-Id: <199703052308.AA22231 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: Marc Horowitz <marc at cygnus.com>
Date: Wed, 5 Mar 1997 18:08:28 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <t53n2siw043.fsf at rover.cygnus.com> from "Marc Horowitz" at Mar 5, 97 03:32:44 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Marc Horowitz wrote:
> "John Wray, Digital DPE, (508) 486-5210 05-Mar-1997 1032" <wray at tuxedo.enet.dec.com> writes:
>
> >> i) What happens to the context if the routine fails for some reason
> >> (maybe the implementation doesn't support transferrable contexts)?
> >> Should the input context still be made inaccessible?
>
> I think the context should be made inaccessible. This is clear and
> unambiguous. If the implementation doesn't support transferrable
> contexts, then there the flags returned from
> gss_init/accept_sec_context will indicate this. If there's some other
> failure, I can't imagine any kind of sensible recovery process.
I don't like this idea. My analogy would be a file descriptor on
which I try to seek but it happens to be a pipe. I would complain
when the OS closed the file because of this error.
export_sec_context() can fail with the error GSS_S_CONTEXT_EXPIRED.
so can the per-message calls getmic/verifymic/wrap/unwrap.
Neither should delete the context when returning this error.
The operation should be atomic, as Ted wrote. It would be very
counter-intuitive if it did half-work (delete the context) and
half-fail (not emit a interprocess token).
-Martin
Received: from cnri by ietf.org id aa06873; 5 Mar 97 20:51 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20086;
5 Mar 97 20:51 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <AAA07111 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 00:06:09 GMT
Message-Id: <199703060005.AA25564 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: cat-ietf at mit.edu
Date: Thu, 6 Mar 1997 01:05:47 +0100 (MEZ)
In-Reply-To: <9703051747.AA16193 at ronde.frcl.bull.fr> from "Jacques Lebastard" at Mar 5, 97 06:47:42 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Maybe there is one situation where automatic context deletion by
gss_export_sec_context() causes a problem:
When trying to build a gssapi mechanism that can dynamically load existing
gssapi mechanisms, then one cannot see from the interprocess token emitted
by export_sec_context by which mechanism implementation it was actually
created. The glue-layer would have to add a wrapper when export_sec_context
returns from the mechanism, and this could fail with "out-of-memory".
In this situation it might be impossible to operate atomically.
Mandating a framing for the interprocess token similar to exported
names would improve the situation somewhat, but I doubt it's a panacea.
The exported names are to be specified in *all* details in the
gssapi mechanism specification; interprocess tokens are meaningful to
one specific implementation only, and they should remain like that.
Do we want to do something about this?
Are there other/more routines where layering does/will interfere with
atomic operation?
-Martin
Received: from cnri by ietf.org id aa07653; 5 Mar 97 21:33 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20569;
5 Mar 97 21:33 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <XAA06239 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 23:46:47 GMT
To: Martin.Rex at sap-ag.de
Cc: cat-ietf at mit.edu
Subject: Re: gss_export_sec_context()
References: <199703052308.AA22231 at sap-ag.de>
From: Marc Horowitz <marc at cygnus.com>
Date: 05 Mar 1997 18:44:57 -0500
In-Reply-To: Martin Rex's message of Wed, 5 Mar 1997 18:08:28 -0500 (EST)
Message-Id: <t53g1y9x5s6.fsf at rover.cygnus.com>
Lines: 37
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
Martin Rex <martin.rex at sap-ag.de> writes:
>> > >> i) What happens to the context if the routine fails for some reason
>> > >> (maybe the implementation doesn't support transferrable contexts)?
>> > >> Should the input context still be made inaccessible?
>> >
>> > I think the context should be made inaccessible. This is clear and
>> > unambiguous. If the implementation doesn't support transferrable
>> > contexts, then there the flags returned from
>> > gss_init/accept_sec_context will indicate this. If there's some other
>> > failure, I can't imagine any kind of sensible recovery process.
>>
>> I don't like this idea. My analogy would be a file descriptor on
>> which I try to seek but it happens to be a pipe. I would complain
>> when the OS closed the file because of this error.
I understand your argument that atomic behavior would be nice, and I
agree, but I don't think that all mechanisms can guarantee that this
sort of atomic behavior is possible. Consider a mechanism which had
to do some sort of irrevocable "give away" of a resource, such as
chowning a file to another user. Remember, the context information
does not need to be contained in the token; the token can refer to the
context data elsewhere if that is appropriate for the mechanism.
To use your file descriptor analogy, consider a function which changes
the owner of a file and then releases a lock. If releasing the lock
somehow fails, it is impossible to "unchown" the file. You don't want
to release the lock first due to the nature of locking and races.
It would be nice to either {succeed/create the token/destroy the
context}, or {fail/not create the token/leave the context untouched},
but some mechanisms cannot guarantee one of these states.
With respect to recovery, what do you do if closing a file descriptor
fails? IMHO, this is similar.
Marc
Received: from ietf.org by ietf.org id aa21760; 6 Mar 97 5:58 EST
Received: from Twig.Rodents.Montreal.QC.CA by ietf.org id aa21516;
6 Mar 97 5:48 EST
Received: (from mouse at localhost) by Twig.Rodents.Montreal.QC.CA (8.7.5/8.7.3) id FAA16081; Thu, 6 Mar 1997 05:46:15 -0500 (EST)
Date: Thu, 6 Mar 1997 05:46:15 -0500 (EST)
Sender:ietf-request at ietf.org
From: der Mouse <mouse at rodents.montreal.qc.ca>
Message-Id: <199703061046.FAA16081 at Twig.Rodents.Montreal.QC.CA>
To: ietf at ietf.org
Cc: cat-ietf at mit.edu
Subject: draft-ietf-cat-ftpsec-09.txt
Source-Info: From (or Sender) name not authenticated.
I have a few minor comments on draft-ietf-cat-ftpsec-09.txt.
> CLEAR COMMAND CHANNEL (CCC)
[...]
> protected control channel messages. The CCC command itself must
> be integrity protected.
[...]
> INTEGRITY PROTECTED COMMAND (MIC) and
> CONFIDENTIALITY PROTECTED COMMAND (CONF) and
> PRIVACY PROTECTED COMMAND (ENC)
[...]
> A server may require that the first command after a successful
> security data exchange be CCC, and not implement the protection
> commands at all. In this case, the server should respond with a
[...]
> If the server has completed a security data exchange with the
> client using a mechanism which supports integrity, and requires a
> CCC command due to policy or implementation limitations, it should
How can the CCC command be integrity protected if the server doesn't
implement at least MIC?
> If the server is willing to allow the user named by the USER command
> to log in based on the identity established by the security data
> exchange, it should respond with reply code 232.
Presumably this refers to the response to the USER command; I think
this should be clarified.
> 6. Data Channel Encapsulation
[...]
> When the end of the file is reached, the sender must encode a block
> of zero bytes, and send this final block to the recipient before
> closing the data connection.
This appears to be considering only STRU F, MODE S - ie, the case where
EOF is indicated by closing the data channel. I think it is important
to clarify how the mechanisms of this draft interact with STRU/MODE
combinations that do not involve creating and closing a new data
channel for each file transferred.
Also, this encoding allows data-stream detection of EOF for STRU F,
MODE S transfers, transfers that normally would require closure of the
data connection to indicate EOF. Does this make it possible to
transfer multiple files over a single data connection when this would
not normally be possible? Whether or not, I think this should be
explicitly stated.
> 10. Base 64 Encoding
[...]
> Case must not be ignored when reading commands and replies containing
> base 64 encodings.
This could be misread to imply that (for example) "mic" is not a valid
form of the command keyword for the MIC command.
I also note that no registry is defined for authentication mechanism
name strings - presumably this will be handled by the IANA, but I'd
like to see it explicitly stated; in particular, people developing
mechanisms should be able to determine whom to get a registered name
for their mechanisms from.
der Mouse
mouse at rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Received: from cnri by ietf.org id aa22781; 6 Mar 97 6:51 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06041;
6 Mar 97 6:51 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <JAA24467 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 09:49:57 GMT
Message-Id: <199703060946.AA11371 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: Marc Horowitz <marc at cygnus.com>
Date: Thu, 6 Mar 1997 04:47:03 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <t53g1y9x5s6.fsf at rover.cygnus.com> from "Marc Horowitz" at Mar 5, 97 06:44:57 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Marc Horowitz wrote:
> Martin Rex <martin.rex at sap-ag.de> writes:
> >> > >> i) What happens to the context if the routine fails for some reason
> >> > >> (maybe the implementation doesn't support transferrable contexts)?
> >> > >> Should the input context still be made inaccessible?
> >> >
> >> > I think the context should be made inaccessible. This is clear and
> >> > unambiguous. If the implementation doesn't support transferrable
> >> > contexts, then there the flags returned from
> >> > gss_init/accept_sec_context will indicate this. If there's some other
> >> > failure, I can't imagine any kind of sensible recovery process.
> >>
> >> I don't like this idea. My analogy would be a file descriptor on
> >> which I try to seek but it happens to be a pipe. I would complain
> >> when the OS closed the file because of this error.
>
> I understand your argument that atomic behavior would be nice, and I
> agree, but I don't think that all mechanisms can guarantee that this
> sort of atomic behavior is possible. Consider a mechanism which had
> to do some sort of irrevocable "give away" of a resource, such as
> chowning a file to another user. Remember, the context information
> does not need to be contained in the token; the token can refer to the
> context data elsewhere if that is appropriate for the mechanism.
>
> To use your file descriptor analogy, consider a function which changes
> the owner of a file and then releases a lock. If releasing the lock
> somehow fails, it is impossible to "unchown" the file. You don't want
> to release the lock first due to the nature of locking and races.
>
> It would be nice to either {succeed/create the token/destroy the
> context}, or {fail/not create the token/leave the context untouched},
> but some mechanisms cannot guarantee one of these states.
I'm not sure this applies here. Context export is not an irreversible
operation. Even if a gssapi mechanism wants to implement a policy for
context "delegation", a process that just exported a context should
always be allowed to reimport the context immediately. I think this makes
it impossible to have irreversible operations during context export.
>
> With respect to recovery, what do you do if closing a file descriptor
> fails? IMHO, this is similar.
If I was just reading the file, I ignore it completely.
If I was writing the file, then I might have to worry if that data
that I was writing needs to be readable at some point in the future.
For context deletion, I basically ignore the returned status at the
application layer; I might log the event under "curiosities".
A gssapi security context doesn't do "buffering" at any level, so
it is a readonly object for the application. A failure upon context
deletion is "interesting during development / for debugging" at best,
it should never affect the operation of an application.
-Martin
Received: from ietf.org by ietf.org id aa27328; 6 Mar 97 9:59 EST
Received: from ietf.ietf.org by ietf.org id aa26286; 6 Mar 97 9:43 EST
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-11.txt
Date: Thu, 06 Mar 1997 09:43:27 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26286 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.
Note: This revision reflects comments received during the last call period.
Title : NBMA Next Hop Resolution Protocol (NHRP)
Author(s) : J. Luciani, D. Katz, D. Piscitello, B. Cole
Filename : draft-ietf-rolc-nhrp-11.txt
Pages : 48
Date : 03/05/1997
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-11.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rolc-nhrp-11.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-11.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: <19970305145755.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rolc-nhrp-11.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rolc-nhrp-11.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305145755.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28288; 6 Mar 97 10:05 EST
Received: from ietf.ietf.org by ietf.org id aa26300; 6 Mar 97 9:43 EST
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-hethmon-mlst-command-ftp-01.txt
Date: Thu, 06 Mar 1997 09:43:32 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26300 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : MLST Command and Extensions to FTP
Author(s) : P. Hethmon
Filename : draft-hethmon-mlst-command-ftp-01.txt
Pages : 10
Date : 03/05/1997
In order to overcome the problems inherent in the current FTP LIST output,
a new command is needed to transfer standardized listing information from
Server-FTP to Client-FTP. In addition, a way for the Server-FTP to let the
Client-FTP know of this capability without imposing on the Client-FTP to
randomly try new commands is needed. This proposal meets both of these
requirements.
This proposal also extends the FTP protocol to allow character sets other
than US-ASCII[1] by allowing the transmission of 8-bit characters and the
recommended use of UTF-8[2] encoding.
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-hethmon-mlst-command-ftp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hethmon-mlst-command-ftp-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-hethmon-mlst-command-ftp-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.
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: <19970305151902.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hethmon-mlst-command-ftp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hethmon-mlst-command-ftp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305151902.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28297; 6 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa26217; 6 Mar 97 9:43 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-warwick-tokenring-01.txt
Date: Thu, 06 Mar 1997 09:43:19 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26217 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Dedicated Token Ring Interface MIB
Author(s) : K. Lee, T. Warwick
Filename : draft-warwick-tokenring-01.txt
Pages : 36
Date : 03/05/1997
This document contains an extract from Draft 7 of the IEEE standard 802.5R
"Dedicated Token Ring". The extract comprises the Interface MIB for the
Dedicated Token Ring interface, in SNMPv2 format. Draft 7 is now
undergoing an IEEE sponsor ballot that is expected to complete in April
1997, and has also been submitted for ballot to ISO. No major changes to
the MIB are expected as a result of these ballots.
802.5R is a standard that encompasses the existing 802.5 token-passing
method of operation, and also defines a new duplex method of operation
for use only on dedicated point to point links, that does not use tokens
for data transmission.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-warwick-tokenring-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-warwick-tokenring-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-warwick-tokenring-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.
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: <19970305134623.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-warwick-tokenring-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-warwick-tokenring-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305134623.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28298; 6 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa26182; 6 Mar 97 9:43 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: find at bunyip.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-find-cip-ldap-01.txt
Date: Thu, 06 Mar 1997 09:43:12 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26182 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 Common Indexing Protocol
Working Group of the IETF.
Title : A Tagged Index Object for use
in the Common Indexing Protocol
Author(s) : R. Hedberg, B. Greenblatt, R. Moats, M. Wahl
Filename : draft-ietf-find-cip-ldap-01.txt
Pages : 18
Date : 03/05/1997
This document defines a mechanism by which information servers can exchange
indices of information from their databases by making use of the Common
Indexing Protocol (CIP). This document defines the structure of the index
information being exchanged, as well as a the structure of the index
information being exchanged, as well as a the Indexing Protocol. It is
assumed that the structures defined here can be used by X.500 DSAs, LDAP
servers, whois++ servers, CCSO servers and many others.
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-find-cip-ldap-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-find-cip-ldap-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-find-cip-ldap-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.
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: <19970305133303.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-find-cip-ldap-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-find-cip-ldap-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305133303.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28303; 6 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa26250; 6 Mar 97 9:43 EST
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-leiba-imap-idle-00.txt
Date: Thu, 06 Mar 1997 09:43:24 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26250 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IMAP4 IDLE command
Author(s) : B. Leiba
Filename : draft-leiba-imap-idle-00.txt
Pages : 4
Date : 03/05/1997
The Internet Message Access Protocol [IMAP4] requires a client to poll the
server for changes to the selected mailbox (new mail, deletions). It's
often more desirable to have the server transmit updates to the client in
real time. This allows a user to see new mail immediately. It also helps
some real-time applications based on IMAP, which might otherwise need to
poll extremely often (such as every few seconds). (While the spec actually
does allow a server to push EXISTS responses aysynchronously, a client
can't expect this behaviour and must poll.)
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-leiba-imap-idle-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-leiba-imap-idle-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-leiba-imap-idle-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: <19970305140412.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-leiba-imap-idle-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-leiba-imap-idle-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305140412.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28284; 6 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa26233; 6 Mar 97 9:43 EST
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-jeya-vlan-8021q-mib-00.txt
Date: Thu, 06 Mar 1997 09:43:22 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26233 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Definitions of Managed Objects for
IEEE 802.1q Virtual LAN Bridges
Author(s) : I. Jeyasubramanian
Filename : draft-jeya-vlan-8021q-mib-00.txt
Pages : 12
Date : 03/05/1997
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 bridges based on the
IEEE 802.1q draft standard between Local Area Network (LAN) segments.
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-jeya-vlan-8021q-mib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-jeya-vlan-8021q-mib-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-jeya-vlan-8021q-mib-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: <19970305135022.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-jeya-vlan-8021q-mib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-jeya-vlan-8021q-mib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305135022.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28290; 6 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa26166; 6 Mar 97 9:43 EST
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-faynberg-telephone-sw-net-00.txt
Date: Thu, 06 Mar 1997 09:43:10 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26166 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Proposal for Internet and Public Switched Telephone
Networks (PSTN) Internetworking
Author(s) : I. Faynberg, M. Krishnaswamy, H. Lu
Filename : draft-faynberg-telephone-sw-net-00.txt
Pages : 10
Date : 03/05/1997
The purpose of this Internet Draft is to start discussion on the issues
involved in interconnecting Internet and Public Switched Networks so as to
provide more effective media than either network type can do presently.
Interworking of the Internet and PSTNs, based on open well-defined
interfaces, will promote interoperability of both the networks and systems
built by different vendors.
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-faynberg-telephone-sw-net-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-faynberg-telephone-sw-net-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-faynberg-telephone-sw-net-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: <19970305143610.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-faynberg-telephone-sw-net-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-faynberg-telephone-sw-net-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305143610.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28286; 6 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa26321; 6 Mar 97 9:43 EST
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: dns-security at tis.com
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-lewis-dnsnxt-semantics-00.txt
Date: Thu, 06 Mar 1997 09:43:35 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26321 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Semantics of DNS NXT Resource Records
Author(s) : E. Lewis, O. Gudmundsson
Filename : draft-lewis-dnsnxt-semantics-00.txt
Pages : 16
Date : 03/05/1997
In "Domain Name System Security Extensions" (RFC 2065) the NXT Resource
Record (along with SIG RR and KEY RR) is introduced to allow for secure
denial of existence of either a domain name or a RRSet belonging to an
existing domain name. The set of NXT records within a zone create a
virtual "chain" of RRSets within a zone by indicating, for each name within
a zone, the RRSets for which it owns records and the next name in the zone.
RFC 2065 discusses security extensions for static DNS zones. An Internet
Draft, draft-ietf-dnssec-update-04.txt, becoming an RFC describes security
in DNS zone which can be dynamically updated. In this document, the
authors build upon them to:
- define some terms used colloquially in the working group
- describe the semantics of the NXT record in greater detail
than the two existing documents, in order to achieve interoperability
- introduce and discuss unresolved issues involving NXT records
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-lewis-dnsnxt-semantics-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-lewis-dnsnxt-semantics-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-lewis-dnsnxt-semantics-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: <19970305173743.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-lewis-dnsnxt-semantics-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-lewis-dnsnxt-semantics-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305173743.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28293; 6 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa26201; 6 Mar 97 9:43 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-warwick-tokenring-arch-01.txt
Date: Thu, 06 Mar 1997 09:43:17 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26201 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Dedicated Token Ring Concentrator MIB
Author(s) : K. Lee, T. Warwick
Filename : draft-warwick-tokenring-arch-01.txt
Pages : 39
Date : 03/05/1997
This document contains an extract from Draft 7 of the IEEE standard 802.5R
"Dedicated Token Ring". The extract comprises the MIB for the Dedicated
Token Ring Concentrator, in SNMPv2 format. Draft 7 is now undergoing an
IEEE sponsor ballot that is expected to complete in April 1997, and has
also been submitted for ballot to ISO. No major changes to the MIB are
expected as a result of these ballots.
802.5R is a standard that encompasses the existing 802.5 token-passing
method of operation, and also defines a new duplex method of operation
for use only on dedicated point to point links, that does not use tokens
for data transmission.
The architecture of a DTR Concentrator is defined in the 802.5R standard.
It is a MAC layer bridging device, which uses a new set of forwarding rules
that ease interoperability between source routing and transparent bridging
in an 802.5 LAN. The DTR Concentrator MIB is derived from the Source
Routing and Transparent Bridge MIBs (RFCs 1525 and 1493).
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-warwick-tokenring-arch-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-warwick-tokenring-arch-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-warwick-tokenring-arch-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.
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: <19970305134343.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-warwick-tokenring-arch-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-warwick-tokenring-arch-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305134343.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28304; 6 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa26149; 6 Mar 97 9:43 EST
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-romanov-00.txt
Date: Thu, 06 Mar 1997 09:43:06 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26149 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Practical Approach to Improving Scalability and
Interoperability of SNMP Applications
Author(s) : A. Romanov
Filename : draft-rfced-info-romanov-00.txt
Pages : 34
Date : 03/04/1997
The goal of this memo is to provide a simple solution for apparent
practical problem of scalability and interoperability of network
management applications.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-rfced-info-romanov-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-romanov-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-rfced-info-romanov-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: <19970304165929.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-romanov-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-romanov-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970304165929.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28248; 6 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa26275; 6 Mar 97 9:43 EST
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-exp-elliston-00.txt
Date: Thu, 06 Mar 1997 09:43:29 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26275 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Encapsulating IP with the Small Computer System
Interface
Author(s) : B. Elliston
Filename : draft-rfced-exp-elliston-00.txt
Pages : 4
Date : 03/05/1997
As the capacity of local area networks increases to meet the demands of
high volume application data, there is a class of network intensive
problems which may be applied to small clusters of workstations with high
bandwidth interconnection.
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-exp-elliston-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-exp-elliston-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-rfced-exp-elliston-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: <19970305150417.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-exp-elliston-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-exp-elliston-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305150417.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa00179; 6 Mar 97 10:30 EST
Received: from ietf.ietf.org by ietf.org id aa29794; 6 Mar 97 10:24 EST
To: ietf at ietf.org
Subject: Re: MUX Modems (was Re: RFC 1990)
Sender:ietf-request at ietf.org
From: I <JonDavis at hehe.com>
Date: Thu, 06 Mar 1997 10:24:55 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703061024.aa29794 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
It appears perhaps you have mistaken my endeavors of reverse multiplexing
(multiple lines, one connection) on POTS lines with standard multiplexing
(single modem, multiple uses). Other than the structure for RFC 1990, no
modem (that I know of) is capable of containing more than one telephone
line for a single purpose==higher data bandwidth. A single 2-line
56k-compatible modem in this case would reach speeds of 2 B channels in the
ISDN world, at the mere cost of two standard modem connections.
Please e-mail me if I am mistaken that there are no such modems. I would
like to pursue this if no one already has or if no one considers it a waste
of time.
When I have completed appropriate research, I will present the entire
outline (in the form of a URL) to IETF to approach standardization...
again, that is another thing I am open to comments about.
-Jon Davis
NewBreed Communications
http://www.interact-net.com/design
jon at interact-net.com
Received: from cnri by ietf.org id aa05789; 6 Mar 97 11:37 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12296;
6 Mar 97 11:37 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <OAA04891 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 14:31:43 GMT
Message-Id: <199703061431.JAA02485 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Comments solicited re negotiated mechanism action
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 06 Mar 1997 09:31:38 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
CAT/negotiated mechanism-interested people:
When Simple Negotiation (draft-ietf-cat-snego-02.txt) was discussed at the
San Jose meeting, controversy arose around interest in development of an
alternate proposal which would apply protection to the negotiation process.
The working plan of record, as cited in the San Jose minutes, was that
an alternate proposal would be defined and circulated in January for
group comparison with SNEGO in February, at which point the group would
consider an advancement recommendation. I believe that there's group
consensus on the value of advancing a negotiated mechanism, but the
alternate proposal contemplated at San Jose has not yet emerged.
Shall we proceed to WG Last-Call on advancement of draft-ietf-cat-snego-02.txt
to Proposed Standard, is alternate proposal development active with a
new target date, and/or does anyone have other suggestions or preferences
to offer as to how the group should now proceed in this area? I'd appreciate
any comments to the list by Friday, 14 March.
Thanks,
--jl
Received: from ietf.org by ietf.org id aa08292; 6 Mar 97 12:00 EST
Received: from cnri by ietf.org id aa07901; 6 Mar 97 11:54 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa12606;
6 Mar 97 11:54 EST
Received: from garlic.com by venera.isi.edu (5.65c/5.61+local-26)
id <AA22328>; Thu, 6 Mar 1997 08:51:49 -0800
Received: from WW2 by garlic.com (8.8.5/4.03)
id QAA73270; Thu, 6 Mar 1997 16:51:14 GMT
Date: Thu, 6 Mar 1997 16:51:14 GMT
Message-Id: <199703061651.QAA73270 at garlic.com>
Sender:ietf-request at ietf.org
From: Anne & Lynn Wheeler <lynn at garlic.com>
To: ietf at isi.edu
Subject: my index & restored RFCs
Reply-To: Anne & Lynn Wheeler <lynn at garlic.com>
Source-Info: From (or Sender) name not authenticated.
noticed bunch of restored RFCs went up yesterday at ISI and today
at internic ... i've modified my index
http://www.garlic.com/~lynn/rfcietf.html
to support the filename variation (i.e. rfcon###.txt instead of
rfc###.txt).
Received: from cnri by ietf.org id aa13219; 6 Mar 97 12:39 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13712;
6 Mar 97 12:39 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <PAA06694 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 15:11:22 GMT
Message-Id: <9703061503.AA29664 at us1rmc.bb.dec.com>
Date: Thu, 6 Mar 97 10:03:18 EST
From: "John Wray, Digital DPE, (508) 486-5210 06-Mar-1997 0950" <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: OIDs and OID sets (again)
Precedence: bulk
Martin wrote:
>John Wray, Digital DPE, wrote:
>> I think we still have a minor problem with dynamic vs. static OIDs & OID sets.
>>
>> The consensus from the San Jose meeting was that we should remove the str<->oid
>> functions from the GSSAPI spec with the purpose of making all GSSAPI-created
>> OIDs static (non-freeable), and we subsequently seem to have reached agreement
>> that OID-sets should be dynamically allocated (i.e. the application must call
>> gss_release_oid_set() to free them).
>
>Actually, this is interesting:
>We agreed that the application must call gss_release_oid_set() to RELEASE
>them.
>
>We didn't discuss if you are allowed to pass OID_sets to add_oid_set_member
>OTHER than those created by create_empty_oid_set and those modified
>by add_oid_set_member.
>
>I would object to any application that tries to feed into add_oid_set_member
>an OID_set that was returned from any of acquire_cred(), add_cred(),
>indicate_mechs(), inquire_cred(), inquire_mechs_for_name and
>inquire_names_for_mech(). Otherwise all OID_sets will have to be completely
>dynamic, especially the one returned from indicate_mechs.
I don't think we need to support OID-sets that were built "by hand" by the
application as input to add_oid_set_member() (after all, if you want to
roll-your-own OID-sets, that's what create_empty_oid_set() and
add_oid_set_member() are for); however it seems unnecessarily restrictive to
prevent the application from using any other GSSAPI-create OID-set. For
example, I could imagine an application that wanted to create a credential just
like an existing one, but with two specific additional mechanisms. It could
call inquire_cred() to get the mechanisms for the existing credential, then
add_oid_set() twice to add the two new mechanism OIDs, then acquire_cred() to
create a new credential. I don't see why we should prohibit this behavior
(even though the app could just call add_cred twice to get the same effect).
I don't see a problem with all OID-sets being dynamic. Indeed, the decision in
V1 to define some OIDs as being static led to all sorts of problems which we
still haven't really solved. The OID-set you mention - the one returned by
indicate_mechs - will have to be specified as dynamic anyway (or at least, the
applicationj will have to invoke gss_release_oid_set() to delete it), since
that's the only way to support dynamic loading of mechanisms.
John
Received: from cnri by ietf.org id aa19107; 6 Mar 97 14:05 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15387;
6 Mar 97 14:05 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <PAA08171 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 15:45:53 GMT
Message-Id: <9703061538.AA02594 at us1rmc.bb.dec.com>
Date: Thu, 6 Mar 97 10:38:29 EST
From: "John Wray, Digital DPE, (508) 486-5210 06-Mar-1997 1004" <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: OIDs and OID sets (again)
Precedence: bulk
Martin wrote:
>To avoid ANY possible problems with different heap allocators, especially
>in shared library environments, it is necessary that objects are entirely
>managed by one single service provider (library). I.e. oid_sets returned
>by a gssapi mechanism have to completely managed and owned by the mechanism.
>
>How a mechanism composes compound objects is a local matter (i.e.
>implementation detail outside of the spec). If a mechanism creates oid_sets
>that refer to static OID-elements octet strings, then it is responsible to
>handle them correctly within gss_release_oid_set.
I don't think this is right. If the _mechanism_ creates static OID-elements
within OID-sets, that's fine, but that's an internal matter between GSSAPI and
the mechanism. What GSSAPI returns to the application should be a fully
dynamic OID-set, or at least something that behaves as if it were fully dynamic
as far as the application is concerned. If a particular GSSAPI/mechanism
implementation wants to optimize this by using static elements, that's OK
provided the application-visible behavior of the sets isn't affected.
There is no defined internal API between "GSSAPI" and "the mechanism", and I
think that's the problem.
>Glue layers that add up gssapi mechanisms to a multimechanism will have
>either have to know about the nature of the oid_sets of the submechanisms,
>or they will have to register or clone the oid_sets while they still know
>which submechanism created the oid_set, so that it can later be released
>correctly.
It's never been an explicit requirement that the GSSAPI spec should support
recursive implementations - i.e. implementations where two mechanisms that each
export a single-mechanism GSSAPI are joined together with a glue layer to
export one multi-mechanism GSSAPI. I expect that an efficient implementation
of this model would require more than just GSSAPI as the interface between the
individual mechanisms and the glue layer.
If glue-layers constructed like this have to clone OID-sets, so be it.
I believe that once we define a GSS-SPI to help the construction of
mechanism-independent GSSAPI libraries, we can deal with this. While most of
the functionality of this SPI would be to allow the GSSAPI layer to invoke
per-mechanism functions (probably mostly single-mechanism analogs of the GSSAPI
functions), it can also include functions exported by GSSAPI that a mechanism
implementation can call. So the GSS-SPI could include GSSAPI-provided
gss_create_empty_oid_set() and gss_add_oid_set_member() functions, allowing any
mechanism to create GSS-compliant OID-sets, and conformance to this SPI by a
machanism would include a requirement that all OID-sets passed to GSSAPI by a
mechanism would be created using these functions. This would remove the need
for cloning OID-sets, since the GSSAPI layer would be responsible for all
OID-set storage management.
John
Received: from cnri by ietf.org id aa21273; 6 Mar 97 14:42 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16090;
6 Mar 97 14:42 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <QAA08919 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 16:03:41 GMT
Message-Id: <c=CA%a=_%p=NorTel_Secure_Ne%l=GRANNY-970306155202Z-14401 at bwdldb.ott.bnr.ca>
From: Carlisle Adams <Cadams at entrust.com>
To: "'cat-ietf at mit.edu'" <cat-ietf at mit.edu>,
"'linn at cam.ov.com'" <linn at cam.ov.com>
Subject: RE: Comments solicited re negotiated mechanism action
Date: Thu, 6 Mar 1997 10:52:02 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 43 TEXT
Precedence: bulk
Hi,
>----------
>From: linn at cam.ov.com[SMTP:linn at cam.ov.com]
>Sent: Thursday, March 06, 1997 9:31 AM
>To: cat-ietf at mit.edu
>Cc: linn at cam.ov.com
>Subject: Comments solicited re negotiated mechanism action
>
>CAT/negotiated mechanism-interested people:
>
>When Simple Negotiation (draft-ietf-cat-snego-02.txt) was discussed at the
>San Jose meeting, controversy arose around interest in development of an
>alternate proposal which would apply protection to the negotiation process.
>The working plan of record, as cited in the San Jose minutes, was that
>an alternate proposal would be defined and circulated in January for
>group comparison with SNEGO in February, at which point the group would
>consider an advancement recommendation. I believe that there's group
>consensus on the value of advancing a negotiated mechanism, but the
>alternate proposal contemplated at San Jose has not yet emerged.
>
>Shall we proceed to WG Last-Call on advancement of
>draft-ietf-cat-snego-02.txt
>to Proposed Standard, is alternate proposal development active with a
>new target date, and/or does anyone have other suggestions or preferences
>to offer as to how the group should now proceed in this area? I'd appreciate
>any comments to the list by Friday, 14 March.
The way I remember the meeting, the alternate proposal had a hard
deadline. Since that deadline has now passed, it seems (in fairness to
the SNEGO authors) that the existing draft should go to Last Call. Of
course this does not prevent the potential authors of the alternate
proposal from going ahead and submitting a draft anyway. However, if
there really is group consensus on the value of a negotiated mechanism
(and I agree with John that there seems to be), then I see no reason to
continue holding up last call...
--------------------------------------
Carlisle Adams
Entrust Technologies
cadams at entrust.com
---------------------------------------
Received: from cnri by ietf.org id aa22569; 6 Mar 97 15:16 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16769;
6 Mar 97 15:16 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA14595 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 18:07:40 GMT
Date: Thu, 6 Mar 1997 13:07:19 -0500
Message-Id: <199703061807.NAA18788 at lurch.mit.edu>
From: Theodre Ts'o <tytso at lurch.mit.edu>
To: Martin.Rex at sap-ag.de
Cc: J.Lebastard at frcl.bull.fr, cat-ietf at mit.edu
In-Reply-To: <199703052023.AA10310 at sap-ag.de> (message from Martin Rex on Wed,
5 Mar 1997 15:24:06 -0500 (EST))
Subject: Re: gss_export_sec_context()
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Martin Rex <martin.rex at sap-ag.de>
Date: Wed, 5 Mar 1997 15:24:06 -0500 (EST)
It's true that RFC2078 says that "the context will be invalid
after export", so it might need to be clarified, but the C-Bindings
and Ted's original proposal pass the context_handle by reference --
so that it can be wiped when the operation succeeds.
Well, given you calling gss_delete_sec_context on an invalid context is
undefined, I'd think RFC-2078 is quite clear, but we can make things
much more explicit in the C-bindings. Certainly the krb5
export_sec_context implementation that I've done frees the context upon
a successful contextr export.
- Ted
Received: from cnri by ietf.org id aa24255; 6 Mar 97 16:15 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17944;
6 Mar 97 16:15 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA14497 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 18:04:54 GMT
Date: Thu, 6 Mar 1997 13:04:21 -0500
Message-Id: <199703061804.NAA18784 at lurch.mit.edu>
From: Theodre Ts'o <tytso at lurch.mit.edu>
To: marc at cygnus.com
Cc: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
In-Reply-To: <t53n2siw043.fsf at rover.cygnus.com> (message from Marc Horowitz on
05 Mar 1997 15:32:44 -0500)
Subject: Re: gss_export_sec_context()
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Marc Horowitz <marc at cygnus.com>
Date: 05 Mar 1997 15:32:44 -0500
I think the context should be made inaccessible. This is clear and
unambiguous. If the implementation doesn't support transferrable
contexts, then there the flags returned from
gss_init/accept_sec_context will indicate this. If there's some other
failure, I can't imagine any kind of sensible recovery process.
The recovery process is easy; just free the flat exportable security
context token that you were busy building. We have it in the krb5 code
already; first you build the exportable flat context token, and only
after you've successfully built it, do you free the gss context.
- Ted
Received: from cnri by ietf.org id aa24391; 6 Mar 97 16:20 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18025;
6 Mar 97 16:20 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA13224 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 17:36:43 GMT
Message-Id: <9703061723.AA11366 at us1rmc.bb.dec.com>
Date: Thu, 6 Mar 97 12:23:54 EST
From: "John Wray, Digital DPE, (508) 486-5210 06-Mar-1997 1147" <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: gss_export_sec_context()
Precedence: bulk
Martin writes:
>>
>> >The equivalent of delete_sec_context() should be called as the very last
>> >action of export_context().
>>
>> With the one proviso that not all the functionality of delete_sec_context() may
>> be wanted: in particular, if some context-specific state has to be retained in
>> order for the context to be imported in another process, that state obviously
>> shouldn't be deleted.
>
>Your last comment frightens me. You should not keep ANY context-specific
>state around in the process image of the process that does the export!
>
>(1) It's NOT ok for a gss-api mechanism to leak memory for
> context_export/context_import activity.
>(2) An application may decide to memset an exported security context to
> zero, while the gssapi mechanism must still conform to (1).
>(3) A context import may fail with GSS_S_CONTEXT_EXPIRED or other
> error codes, in which case an application will probably do (2).
>(4) The context-exporting process may exit before the exported context
> will be imported by another process.
> (I'm going to implement security context caching for specific
> client applications that will require this characteristic,
> mainly to improve performance for public key based authentication
> and to save round trips on the average).
Hmm. These are new requirements (at least, as far as I know, they've never
been stated expicitly before).
I've been viewing an interprocess token sort-of like a capability - something
that can be used to get at a context by the second process. There's not been
an explicit requirement that all the information needed to re-build the context
is contained in the interprocess token, although that's certainly one way of
implementing it. On the other hand, it should be acceptable to build a kernel
GSSAPI implementation where contexts are maintained in shared protected memory,
and accessed by processes via handles, with the GSSAPI enforcing
access-control. In such a model, the interprocess token provides a way for
access to a given context to be transferred to another process, but the context
itself is never actually passed around.
This sort of implementation has to be able to garbage-collect contexts that the
application has forgotten to delete. This would normally be triggered on
process-exit, but if the app has created an interprocess token, that won't work
if we have to be able to satisfy your requirement 4 above. I guess a context
can always be garbage-collected when it expires.
Should requirement 4 be a requirement on all GSSAPI implementations? Do we
want to mandate how long an exported context will remain importable, after the
original process goes away? Should it last across system reboots, if the
application stores the token in a file, for example? Or can this be left up to
individual implementations? There are already some words to the effect that an
implementation can impose its own access-control on context import/export, so
maybe this covers everything.
I don't believe that memsetting an interprocess token to zero should be the
"approved" way to change your mind about importing it. If you really need this
functionality, it would be better to have an additional
gss_release_exported_context() or gss_release_interprocess_token() call that
would do whatever's necessary to release resources and erase any sensitive
information in the token. That way, if the GSSAPI implementation does save
context information elsewhere than in the token, then it can be scrubbed and
released.
John
Received: from cnri by ietf.org id aa24864; 6 Mar 97 16:35 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18291;
6 Mar 97 16:35 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA14426 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 18:02:17 GMT
Date: Thu, 6 Mar 1997 13:01:55 -0500
Message-Id: <199703061801.NAA18780 at lurch.mit.edu>
From: Theodre Ts'o <tytso at lurch.mit.edu>
To: Martin.Rex at sap-ag.de
Cc: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
In-Reply-To: <199703051940.AA07350 at sap-ag.de> (message from Martin Rex on Wed,
5 Mar 1997 14:41:17 -0500 (EST))
Subject: Re: OIDs and OID sets (again)
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Martin Rex <martin.rex at sap-ag.de>
Date: Wed, 5 Mar 1997 14:41:17 -0500 (EST)
We didn't discuss if you are allowed to pass OID_sets to
add_oid_set_member OTHER than those created by create_empty_oid_set
and those modified by add_oid_set_member.
I would object to any application that tries to feed into
add_oid_set_member an OID_set that was returned from any of
acquire_cred(), add_cred(), indicate_mechs(), inquire_cred(),
inquire_mechs_for_name and inquire_names_for_mech(). Otherwise all
OID_sets will have to be completely dynamic, especially the one
returned from indicate_mechs.
I think OID sets should always be completely dynamic. It simplifies
things immensely. The advantage of making some OID sets be static is
relatively small, given that applications have to always assume that OID
sets be dynamic and call gss_release_oid_set() to avoid memory leaks.
The confusion caused by having some OID_sets being OK for some
operations (like add_oid_set_member()), and some not being OK for some
operations is only going to cause hard-to-find bugs. I really don't
think it's worth the small marginal increase in simplicity in the
mechanism code.
- Ted
Received: from cnri by ietf.org id aa25477; 6 Mar 97 16:58 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18712;
6 Mar 97 16:57 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA18969 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 19:51:15 GMT
Message-Id: <199703061950.LAA02885 at fluffy.cisco.com>
To: Carlisle Adams <Cadams at entrust.com>
Cc: "'cat-ietf at mit.edu'" <cat-ietf at mit.edu>,
"'linn at cam.ov.com'" <linn at cam.ov.com>
Subject: Re: Comments solicited re negotiated mechanism action
In-Reply-To: Your message of "Thu, 06 Mar 1997 10:52:02 EST."
<c=CA%a=_%p=NorTel_Secure_Ne%l=GRANNY-970306155202Z-14401 at bwdldb.ott.bnr.ca>
Date: Thu, 06 Mar 1997 11:50:53 -0800
From: Derrell Piper <piper at cisco.com>
Precedence: bulk
>The way I remember the meeting, the alternate proposal had a hard
>deadline. Since that deadline has now passed, it seems (in fairness to
>the SNEGO authors) that the existing draft should go to Last Call. Of
>course this does not prevent the potential authors of the alternate
>proposal from going ahead and submitting a draft anyway. However, if
>there really is group consensus on the value of a negotiated mechanism
>(and I agree with John that there seems to be), then I see no reason to
>continue holding up last call...
Yeah, that's what I remember too...
Derrell
Received: from cnri by ietf.org id aa28032; 6 Mar 97 17:38 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19598;
6 Mar 97 17:38 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA18317 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 19:35:05 GMT
Message-Id: <199703061934.AA01639 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: protecting empty messages?
To: cat-ietf at mit.edu
Date: Thu, 6 Mar 1997 14:34:25 -0500 (EST)
In-Reply-To: <199703061046.FAA16081 at Twig.Rodents.Montreal.QC.CA> from "der Mouse" at Mar 6, 97 05:46:15 am
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Ooops, there seems to be an assumption in ftpsec that I do not
consider obvious from the GSS-API spec:
Support for "protecting" zero-length messages:
draft-ietf-cat-ftpsec-09.txt:
6. Data Channel Encapsulation
[...]
The sender must take the input byte stream, and break it up into
blocks such that each block, when encoded using a security mechanism
specific procedure, will be no larger than the buffer size negotiated
by the client with the PBSZ command. Each block must be encoded,
then transmitted with the length of the encoded block prepended as a
four byte unsigned integer, most significant byte first.
When the end of the file is reached, the sender must encode a block
of zero bytes, and send this final block to the recipient before
closing the data connection.
The recipient will read the four byte length, read a block of data
that many bytes long, then decode and verify this block with a
security mechanism specific procedure. This must be repeated until a
block encoding a buffer of zero bytes is received. This indicates
the end of the encoded byte stream.
This sounds like GSS-API mechanisms should be able to wrap an
"empty message", and that an "empty buffer" returned from gss_unwrap
with status GSS_S_COMPLETE is supposed to mean "empty message" instead
of "no message, strange mechanism behaviour".
If support for protection of emtpy messages is to be required by
GSS-API, then I'd like this to be explicitly mentioned in the spec.
-Martin
Received: from cnri by ietf.org id aa28589; 6 Mar 97 17:59 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19980;
6 Mar 97 17:59 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA21099 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 20:43:55 GMT
To: Theodre Ts'o <tytso at lurch.mit.edu>
Cc: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
Subject: Re: gss_export_sec_context()
References: <199703061804.NAA18784 at lurch.mit.edu>
From: Marc Horowitz <marc at cygnus.com>
Date: 06 Mar 1997 15:43:53 -0500
In-Reply-To: "Theodre Ts'o"'s message of Thu, 6 Mar 1997 13:04:21 -0500
Message-Id: <t533eu8wy2e.fsf at rover.cygnus.com>
Lines: 12
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
"Theodre Ts'o" <tytso at lurch.mit.edu> writes:
>> The recovery process is easy; just free the flat exportable security
>> context token that you were busy building. We have it in the krb5 code
>> already; first you build the exportable flat context token, and only
>> after you've successfully built it, do you free the gss context.
This is fine for krb5, which can atomically export a context. As my
previous messages have stated, I'm unconvinced that this is possible
for all mechanisms.
Marc
Received: from cnri by ietf.org id aa28915; 6 Mar 97 18:07 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20233;
6 Mar 97 18:07 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA14609 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 18:08:18 GMT
Message-Id: <199703061807.KAA10076 at imo.plaintalk.bellevue.wa.us>
Content-Type: text/plain
Mime-Version: 1.0 (NeXT Mail 3.3 v118.2)
From: Dennis Glatting <dennis.glatting at plaintalk.bellevue.wa.us>
Date: Thu, 6 Mar 97 10:07:51 -0800
To: John Linn <linn at cam.ov.com>
Subject: Re: Comments solicited re negotiated mechanism action
Cc: cat-ietf at mit.edu
Reply-To: dennis.glatting at plaintalk.bellevue.wa.us
References: <199703061431.JAA02485 at gza-client1.cam.ov.com>
Precedence: bulk
> Date: Thu, 06 Mar 1997 09:31:38 -0500
> From: John Linn <linn at cam.ov.com>
>
> CAT/negotiated mechanism-interested people:
>
> When Simple Negotiation (draft-ietf-cat-snego-02.txt) was
> discussed at the San Jose meeting, controversy arose around
> interest in development of an alternate proposal which would
> apply protection to the negotiation process. The working plan
> of record, as cited in the San Jose minutes, was that an
> alternate proposal would be defined and circulated in January
> for group comparison with SNEGO in February, at which point the
> group would consider an advancement recommendation. I
> believe that there's group consensus on the value of advancing
> a negotiated mechanism, but the alternate proposal
> contemplated at San Jose has not yet emerged.
>
> Shall we proceed to WG Last-Call on advancement of
> draft-ietf-cat-snego-02.txt to Proposed Standard, is
> alternate proposal development active with a new target date,
> and/or does anyone have other suggestions or preferences to
> offer as to how the group should now proceed in this area? I'd
> appreciate any comments to the list by Friday, 14 March.
>
I was unable to attend San Jose, please forgive my ignorance.
See you in Memphis. :)
I vote for snego, as it stands, to advance to informational or
experimental and another approach pursued. Perhaps too we
should start on GSS-APIv3, not backward compatible with v1 and
v2, and addresses GSS-APIv2's shortcomings, such as nego,
configuration, thread safety, single sign-on, etc.
-dpg
Received: from cnri by ietf.org id aa28961; 6 Mar 97 18:08 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20254;
6 Mar 97 18:08 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA14926 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 18:15:05 GMT
Date: Thu, 6 Mar 1997 13:14:27 -0500
Message-Id: <199703061814.NAA18793 at lurch.mit.edu>
From: Theodre Ts'o <tytso at lurch.mit.edu>
To: Martin.Rex at sap-ag.de
Cc: cat-ietf at mit.edu
In-Reply-To: <199703060005.AA25564 at sap-ag.de> (message from Martin Rex on Thu,
6 Mar 1997 01:05:47 +0100 (MEZ))
Subject: Re: gss_export_sec_context()
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Martin Rex <martin.rex at sap-ag.de>
Date: Thu, 6 Mar 1997 01:05:47 +0100 (MEZ)
When trying to build a gssapi mechanism that can dynamically load existing
gssapi mechanisms, then one cannot see from the interprocess token emitted
by export_sec_context by which mechanism implementation it was actually
created. The glue-layer would have to add a wrapper when export_sec_context
returns from the mechanism, and this could fail with "out-of-memory".
In this situation it might be impossible to operate atomically.
This is a good point. There are some ways to get around this problem in
principal (preallocate a very large buffer before calling the
mechanism-specific export_sec_context(), and then use that large buffer
to store the exported token plus the mechanism glue framing).
Mandating a framing for the interprocess token similar to exported
names would improve the situation somewhat, but I doubt it's a panacea.
The exported names are to be specified in *all* details in the
gssapi mechanism specification; interprocess tokens are meaningful to
one specific implementation only, and they should remain like that.
Well, we could mandate that the token has to be framed similar to the
way the initial init_sec_context token is framed. That specifies much
less (just what has to be at the begining of a token, to disambiguate
one mechanism from another).
Do we want to do something about this?
Are there other/more routines where layering does/will interfere with
atomic operation?
init_sec_context() and accept_sec_context() likely have similar
problems, although in general applications generally assume that the
entire security context negotiation has failed when these errors occur,
instead of trying to retry them somehow.
- Ted
Received: from cnri by ietf.org id aa00113; 6 Mar 97 18:54 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20935;
6 Mar 97 18:54 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <VAA22783 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 21:23:41 GMT
Date: Thu, 6 Mar 1997 16:22:59 -0500 (EST)
From: der Mouse <mouse at rodents.montreal.qc.ca>
Message-Id: <199703062122.QAA17067 at Twig.Rodents.Montreal.QC.CA>
To: Marc Horowitz <marc at cygnus.com>
Cc: jis at mit.edu, linn at cam.ov.com, cat-ietf at mit.edu
Subject: Re: draft-ietf-cat-ftpsec-09.txt
Precedence: bulk
> I believe that all of them are easily addressed editorially, [...]
I suspect you are right. Aside from the pure editorial changes (like
the bit about the 232 reply to USER), everything I mentioned could, for
some possible original intent, be nothing more than a minor
clarificative change, and they all seem to have turned out that way,
with the possible exception of the first one herein, which is still
unclear to me:
>>> protected control channel messages. The CCC command itself must
>>> be integrity protected.
[...]
>>> A server may require that the first command after a successful
>>> security data exchange be CCC, and not implement the protection
>>> commands at all. In this case, the server should respond with a
>> How can the CCC command be integrity protected if the server doesn't
>> implement at least MIC?
> This command was requested by HP, who has implemented it.
Yeah, I too can't quite see the point of CCC, but my point was not so
much that CCC is or isn't useless, as that the document seems to
contradict itself, saying that CCC must be integrity protected and then
stating fairly directly that it is possible to operate without
implementing the command that would be necessary to get that integrity
protection.
>>> 6. Data Channel Encapsulation
[...]
>>> When the end of the file is reached, the sender must encode a block
>>> of zero bytes, [...]
I just now noticed that this could be misunderstood to mean "a block
containing data bytes of value 0x00". While I don't think this is
likely to be a problem in practice, it's easy to fix with a minor
rewording (eg, "a zero-length block of bytes"), and unambiguous clarity
is generally a Good Thing for standards.
>> This appears to be considering only [...] the case where EOF is
>> indicated by closing the data channel.
>> Also, this encoding allows data-stream detection of EOF for STRU F,
>> MODE S transfers, [...]
> I think this issue can be solved by replacing the word "file" with
> the word "data channel", which was the intent.
Aha, yes, if that was the intent then I have no problem with the
mechanism, only with the (former) wording. :-)
> The reason to transmit an encoded block of zero bytes is to protect
> against an attacker prematurely closing the TCP stream.
Heh. Can you say "NT sniper bug"? :-)
>> I also note that no registry is defined for authentication mechanism
>> name strings - presumably this will be handled by the IANA, [...]
> In section 3:
> AUTHENTICATION/SECURITY MECHANISM (AUTH)
> The argument field is a Telnet string identifying a supported
> mechanism. This string is case-insensitive. Values must be
> registered with the IANA, except that values beginning with "X-"
> are reserved for local use.
> Do you think this is insufficient?
No. My apologies; I simply missed that sentence when reading it.
der Mouse
mouse at rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Received: from cnri by ietf.org id aa00451; 6 Mar 97 19:08 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21152;
6 Mar 97 19:08 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA21091 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 20:43:17 GMT
To: der Mouse <mouse at rodents.montreal.qc.ca>
Cc: jis at mit.edu, linn at cam.ov.com
Cc: cat-ietf at mit.edu
Subject: Re: draft-ietf-cat-ftpsec-09.txt
References: <199703061046.FAA16081 at Twig.Rodents.Montreal.QC.CA>
From: Marc Horowitz <marc at cygnus.com>
Date: 06 Mar 1997 15:41:24 -0500
In-Reply-To: der Mouse's message of Thu, 6 Mar 1997 05:46:15 -0500 (EST)
Message-Id: <t534teowy6j.fsf at rover.cygnus.com>
Lines: 110
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
der Mouse <mouse at rodents.montreal.qc.ca> writes:
>> I have a few minor comments on draft-ietf-cat-ftpsec-09.txt.
Thank you for your comments. I believe that all of them are easily
addressed editorially, and therefore do not require me to produce
another draft, but I would like your opinion and the opinions of the
WG members, WG chair, and AD on this.
>> > CLEAR COMMAND CHANNEL (CCC)
>> [...]
>> > protected control channel messages. The CCC command itself must
>> > be integrity protected.
>> [...]
>> > INTEGRITY PROTECTED COMMAND (MIC) and
>> > CONFIDENTIALITY PROTECTED COMMAND (CONF) and
>> > PRIVACY PROTECTED COMMAND (ENC)
>> [...]
>> > A server may require that the first command after a successful
>> > security data exchange be CCC, and not implement the protection
>> > commands at all. In this case, the server should respond with a
>> [...]
>> > If the server has completed a security data exchange with the
>> > client using a mechanism which supports integrity, and requires a
>> > CCC command due to policy or implementation limitations, it should
>>
>> How can the CCC command be integrity protected if the server doesn't
>> implement at least MIC?
This command was requested by HP, who has implemented it. Since it
requires them to implement MIC, at least for CCC, I admit that I'm not
sure why it's worth the effort, but they seem to have implemented
this. If nobody else implements this command as the document
progresses, then the command will have to be dropped due to lack of
interoperating implementations, but we can deal with that then.
>> > If the server is willing to allow the user named by the USER command
>> > to log in based on the identity established by the security data
>> > exchange, it should respond with reply code 232.
>>
>> Presumably this refers to the response to the USER command; I think
>> this should be clarified.
Done.
>> > 6. Data Channel Encapsulation
>> [...]
>> > When the end of the file is reached, the sender must encode a block
>> > of zero bytes, and send this final block to the recipient before
>> > closing the data connection.
>>
>> This appears to be considering only STRU F, MODE S - ie, the case where
>> EOF is indicated by closing the data channel. I think it is important
>> to clarify how the mechanisms of this draft interact with STRU/MODE
>> combinations that do not involve creating and closing a new data
>> channel for each file transferred.
>>
>> Also, this encoding allows data-stream detection of EOF for STRU F,
>> MODE S transfers, transfers that normally would require closure of the
>> data connection to indicate EOF. Does this make it possible to
>> transfer multiple files over a single data connection when this would
>> not normally be possible? Whether or not, I think this should be
>> explicitly stated.
I think this issue can be solved by replacing the word "file" with the
word "data channel", which was the intent. The reason to transmit an
encoded block of zero bytes is to protect against an attacker
prematurely closing the TCP stream. This issue is independent of
structure and mode. To make this completely unambiguous, I can add a
paragraph:
The zero-byte block must be the last data transmitted by the sender
before the data channel TCP connection is closed. If the recipient
sees the connection close before this block is received, or if
additional data arrives after this block, then the recipient should
treat this as a message stream modification. If the server is unable
to send the final block, or detects one of the above conditions when
receiving, it should respond with reply code 535.
This change is clarifying only, not semantic.
>>
>> > 10. Base 64 Encoding
>> [...]
>> > Case must not be ignored when reading commands and replies containing
>> > base 64 encodings.
>>
>> This could be misread to imply that (for example) "mic" is not a valid
>> form of the command keyword for the MIC command.
Good point. I'll clarify this.
>> I also note that no registry is defined for authentication mechanism
>> name strings - presumably this will be handled by the IANA, but I'd
>> like to see it explicitly stated; in particular, people developing
>> mechanisms should be able to determine whom to get a registered name
>> for their mechanisms from.
In section 3:
AUTHENTICATION/SECURITY MECHANISM (AUTH)
The argument field is a Telnet string identifying a supported
mechanism. This string is case-insensitive. Values must be
registered with the IANA, except that values beginning with "X-"
are reserved for local use.
Do you think this is insufficient?
Marc
Received: from cnri by ietf.org id aa00786; 6 Mar 97 19:23 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21379;
6 Mar 97 19:22 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA20395 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 20:27:22 GMT
Message-Id: <199703062026.AA04947 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: John Wray Digital DPE <wray at tuxedo.enet.dec.com>
Date: Thu, 6 Mar 1997 15:26:28 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703061723.AA11366 at us1rmc.bb.dec.com> from "John Wray, Digital DPE," at Mar 6, 97 12:23:54 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Wray, Digital DPE, wrote:
> Martin writes:
> >Your last comment frightens me. You should not keep ANY context-specific
> >state around in the process image of the process that does the export!
> >
> >(1) It's NOT ok for a gss-api mechanism to leak memory for
> > context_export/context_import activity.
> >(2) An application may decide to memset an exported security context to
> > zero, while the gssapi mechanism must still conform to (1).
> >(3) A context import may fail with GSS_S_CONTEXT_EXPIRED or other
> > error codes, in which case an application will probably do (2).
> >(4) The context-exporting process may exit before the exported context
> > will be imported by another process.
> > (I'm going to implement security context caching for specific
> > client applications that will require this characteristic,
> > mainly to improve performance for public key based authentication
> > and to save round trips on the average).
>
>
> Hmm. These are new requirements (at least, as far as I know, they've never
> been stated expicitly before).
That's true, I've never explicitly stated that. But I was trying to
convince Denis Pinkas to use context export for context caching with
these things in mind.
My list of requirements is for interoperability with *our* application,
I don't ask to mandate these requirements for all GSS-API v2 mechanisms
that offer context transfer. How about adding another feature flag
to init_sec_context/accept_sec_context which indicates how robust the
implemented context transfer is?
>
> I've been viewing an interprocess token sort-of like a capability - something
> that can be used to get at a context by the second process. There's not been
> an explicit requirement that all the information needed to re-build the context
> is contained in the interprocess token, although that's certainly one way of
> implementing it. On the other hand, it should be acceptable to build a kernel
> GSSAPI implementation where contexts are maintained in shared protected memory,
> and accessed by processes via handles, with the GSSAPI enforcing
> access-control. In such a model, the interprocess token provides a way for
> access to a given context to be transferred to another process, but the context
> itself is never actually passed around.
>
> This sort of implementation has to be able to garbage-collect contexts that
> the application has forgotten to delete. This would normally be triggered on
> process-exit, but if the app has created an interprocess token, that won't
> work if we have to be able to satisfy your requirement 4 above. I guess a
> context can always be garbage-collected when it expires.
Garbage collection on context expiration should be possible.
GSS-API mechanisms that implement complicated policy stuff around
security context transfers might disqualify themselves for interoperation
with our application anyway, i.e. the overhead for a single operation
(import or export) must not exceed 3 milliseconds, or impact on the
transaction rate will become so significant, that a customer will
probably choose a different product/implementation/gss-api mechanism.
>
> Should requirement 4 be a requirement on all GSSAPI implementations? Do we
> want to mandate how long an exported context will remain importable, after
> the original process goes away? Should it last across system reboots, if the
> application stores the token in a file, for example? Or can this be left up
> to individual implementations? There are already some words to the effect
> that an implementation can impose its own access-control on context
> import/export, so maybe this covers everything.
I plan to cache the security contexts in a file to reuse them in successor
client processes. The server will most probably cache them in shared memory,
because it rarely restarts.
In our application environment a server will (soon) hold up to 10000 security
contexts in parallel, 99% of them dormant in exported state. Contexts will
only be imported to process client requests, and they will be exported right
after the reply for the client has been processed ("protected"). Many of
the clients are GUIs, so the sleeping periods of security contexts can be
arbitrarily long (hours, days, weeks in some cases). I do rely on context
expiring approximately at the same time (clock skew +- 5 Minutes),
independent of their state (imported or exported), so that I can renegotiate
a new context when the existing context is close to expiration or already
expired.
An absolutely required feature for our application is that an exported
security context survives termination of the process which did the
context export.
>
> I don't believe that memsetting an interprocess token to zero should be the
> "approved" way to change your mind about importing it. If you really need
> this functionality, it would be better to have an additional
> gss_release_exported_context() or gss_release_interprocess_token() call that
> would do whatever's necessary to release resources and erase any sensitive
> information in the token. That way, if the GSSAPI implementation does save
> context information elsewhere than in the token, then it can be scrubbed and
> released.
It would be very difficult to do something like releasing an exported
context. Where would it have to be done? In the process which did
the export? That's in general not possible for our application, so
we wouldn't even think about the 5% of case where it might be.
If it would be possible to "release" an exported context from any
process context, then it could be implemented, but we will still have
a considerable amount of leftovers.
-Martin
Received: from cnri by ietf.org id aa01209; 6 Mar 97 19:41 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21634;
6 Mar 97 19:41 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <WAA26548 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 22:51:21 GMT
Date: Thu, 6 Mar 1997 14:51:07 -0800 (PST)
Message-Id: <199703062251.OAA19406 at tree2.Stanford.EDU>
From: schemers at stanford.edu
To: Marc Horowitz <marc at cygnus.com>
Cc: Theodre Ts'o <tytso at lurch.mit.edu>, wray at tuxedo.enet.dec.com,
cat-ietf at mit.edu
Subject: Re: gss_export_sec_context()
In-Reply-To: <t533eu8wy2e.fsf at rover.cygnus.com>
References: <199703061804.NAA18784 at lurch.mit.edu>
<t533eu8wy2e.fsf at rover.cygnus.com>
Precedence: bulk
Marc Horowitz writes:
> "Theodre Ts'o" <tytso at lurch.mit.edu> writes:
>
> >> The recovery process is easy; just free the flat exportable security
> >> context token that you were busy building. We have it in the krb5 code
> >> already; first you build the exportable flat context token, and only
> >> after you've successfully built it, do you free the gss context.
>
> This is fine for krb5, which can atomically export a context. As my
> previous messages have stated, I'm unconvinced that this is possible
> for all mechanisms.
>
What will be the typical failure mode for an application that
wants to export a context and can't? Is it really going to continue
on and do something else with the context, or is it going to delete it
and return an error? Answering that might help answer this question.
roland
Received: from ietf.org by ietf.org id ab01947; 6 Mar 97 20:19 EST
Received: from servo.qualcomm.com by ietf.org id aa01794; 6 Mar 97 20:13 EST
Received: (from karn at localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id RAA27320; Thu, 6 Mar 1997 17:10:31 -0800 (PST)
Date: Thu, 6 Mar 1997 17:10:31 -0800 (PST)
Sender:ietf-request at ietf.org
From: Phil Karn <karn at qualcomm.com>
Message-Id: <199703070110.RAA27320 at servo.qualcomm.com>
To: ietf at ietf.org
Subject: Memphis hotel situation
Source-Info: From (or Sender) name not authenticated.
Well, the Peabody, Holiday Inn Select and Holiday Inn Crowne Plaza are all
completely sold out for the week of the IETF. Anybody have any alternates?
The recurring IETF hotel situation is becoming completely
untenable. Aside from moving the IETF permanently to Las Vegas (if any
US city can handle a group our size, Vegas is it), does anyone have
any ideas to solve this problem?
Phil
Received: from cnri by ietf.org id aa03102; 6 Mar 97 20:33 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22258;
6 Mar 97 20:33 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <AAA29621 at pad-thai.cam.ov.com>; Fri, 7 Mar 1997 00:04:57 GMT
Date: Thu, 6 Mar 1997 19:04:46 -0500 (EST)
From: der Mouse <mouse at rodents.montreal.qc.ca>
Message-Id: <199703070004.TAA17674 at Twig.Rodents.Montreal.QC.CA>
To: Marc Horowitz <marc at cygnus.com>, jis at mit.edu, linn at cam.ov.com,
cat-ietf at mit.edu
Subject: Re: draft-ietf-cat-ftpsec-09.txt
Precedence: bulk
>> [M]y point was not so much that CCC is or isn't useless, as that the
>> document seems to contradict itself, saying that CCC must be
>> integrity protected and then stating fairly directly that it is
>> possible to operate without implementing the command that would be
>> necessary to get that integrity protection.
> I can reword the text to say something like "... and not implement
> the protection commands in the general case." How's that?
That would be fine with me.
der Mouse
Received: from cnri by ietf.org id aa03462; 6 Mar 97 20:36 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22295;
6 Mar 97 20:36 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <WAA26407 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 22:46:25 GMT
To: der Mouse <mouse at rodents.montreal.qc.ca>
Cc: jis at mit.edu, linn at cam.ov.com, cat-ietf at mit.edu
Subject: Re: draft-ietf-cat-ftpsec-09.txt
References: <199703062122.QAA17067 at Twig.Rodents.Montreal.QC.CA>
From: Marc Horowitz <marc at cygnus.com>
Date: 06 Mar 1997 17:45:31 -0500
In-Reply-To: der Mouse's message of Thu, 6 Mar 1997 16:22:59 -0500 (EST)
Message-Id: <t53vi74vdv8.fsf at rover.cygnus.com>
Lines: 23
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
der Mouse <mouse at Rodents.Montreal.QC.CA> writes:
>> >>> protected control channel messages. The CCC command itself must
>> >>> be integrity protected.
>> [...]
>> >>> A server may require that the first command after a successful
>> >>> security data exchange be CCC, and not implement the protection
>> >>> commands at all. In this case, the server should respond with a
>> >> How can the CCC command be integrity protected if the server doesn't
>> >> implement at least MIC?
>> > This command was requested by HP, who has implemented it.
>>
>> Yeah, I too can't quite see the point of CCC, but my point was not so
>> much that CCC is or isn't useless, as that the document seems to
>> contradict itself, saying that CCC must be integrity protected and then
>> stating fairly directly that it is possible to operate without
>> implementing the command that would be necessary to get that integrity
>> protection.
I can reword the text to say something like "... and not implement the
protection commands in the general case." How's that?
Marc
Received: from ietf.org by ietf.org id aa03560; 6 Mar 97 20:38 EST
Received: from works.ingrid.org by ietf.org id aa03513; 6 Mar 97 20:37 EST
Received: by works.ingrid.org (8.8.4/ingrid*mx2) with TCP; Fri, 7 Mar 1997 10:36:41 +0900 (JST)
Date: Fri, 7 Mar 1997 10:36:41 +0900 (JST)
Sender:ietf-request at ietf.org
From: Paul Francis <francis at works.ingrid.org>
Message-Id: <199703070136.KAA00352 at works.ingrid.org>
To: ietf at ietf.org, karn at qualcomm.com
Subject: Re: Memphis hotel situation
Source-Info: From (or Sender) name not authenticated.
>
> untenable. Aside from moving the IETF permanently to Las Vegas (if any
> US city can handle a group our size, Vegas is it), does anyone have
>
I think having all meetings in las vegas is a great idea.
What better place to hammer out rough concensus than at
a roulette table?
PF
Received: from ietf.org by ietf.org id aa05094; 6 Mar 97 21:05 EST
Received: from rip.psg.com by ietf.org id aa05034; 6 Mar 97 21:04 EST
Received: by rip.psg.com
id m0w2oyU-0007zYC; Thu, 6 Mar 97 18:01 PST (Smail3.1.29.1#1)
Message-Id: <m0w2oyU-0007zYC at rip.psg.com>
Date: Thu, 6 Mar 97 18:01 PST
Sender:ietf-request at ietf.org
From: Randy Bush <randy at psg.com>
To: Phil Karn <karn at qualcomm.com>
Cc: ietf at ietf.org
Subject: Re: Memphis hotel situation
References: <199703070110.RAA27320 at servo.qualcomm.com>
Source-Info: From (or Sender) name not authenticated.
> The recurring IETF hotel situation is becoming completely
> untenable. Aside from moving the IETF permanently to Las Vegas (if any
> US city can handle a group our size, Vegas is it), does anyone have
> any ideas to solve this problem?
Vladavostok, Cape Town, Santiago, Havana, ... All beautiful cities, and we
would solve two problems with one hack.
randy
Received: from cnri by ietf.org id aa06979; 6 Mar 97 21:28 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22995;
6 Mar 97 21:28 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <AAA29787 at pad-thai.cam.ov.com>; Fri, 7 Mar 1997 00:08:40 GMT
To: schemers at stanford.edu
Cc: Theodre Ts'o <tytso at lurch.mit.edu>, wray at tuxedo.enet.dec.com,
cat-ietf at mit.edu
Subject: Re: gss_export_sec_context()
References: <199703061804.NAA18784 at lurch.mit.edu>
<t533eu8wy2e.fsf at rover.cygnus.com>
<199703062251.OAA19406 at tree2.Stanford.EDU>
From: Marc Horowitz <marc at cygnus.com>
Date: 06 Mar 1997 19:07:55 -0500
In-Reply-To: schemers at stanford.edu's message of Thu, 6 Mar 1997 14:51:07 -0800 (PST)
Message-Id: <t53pvxcva1w.fsf at rover.cygnus.com>
Lines: 15
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
schemers at stanford.edu writes:
>> What will be the typical failure mode for an application that
>> wants to export a context and can't? Is it really going to continue
>> on and do something else with the context, or is it going to delete it
>> and return an error? Answering that might help answer this question.
Chances are, you won't get that far, because you'll only link against
mechanisms which support the feature if you require it. Once we have
negotiation and some sort of pluggable mechanism support, then this
could happen; I would expect most applications to delete it and try
another available mechanism, but some might downgrade to a
single-process model and take the resulting performance hit.
Marc
Received: from cnri by ietf.org id aa07189; 6 Mar 97 21:39 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23146;
6 Mar 97 21:39 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <AAA01725 at pad-thai.cam.ov.com>; Fri, 7 Mar 1997 00:37:31 GMT
Message-Id: <199703070036.AA22663 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: schemers at stanford.edu
Date: Fri, 7 Mar 1997 01:36:24 +0100 (MEZ)
Cc: cat-ietf at mit.edu
In-Reply-To: <199703062251.OAA19406 at tree2.Stanford.EDU> from "schemers at stanford.edu" at Mar 6, 97 02:51:07 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
schemers at stanford.edu wrote:
> Marc Horowitz writes:
> > "Theodre Ts'o" <tytso at lurch.mit.edu> writes:
> >
> > >> The recovery process is easy; just free the flat exportable security
> > >> context token that you were busy building. We have it in the krb5 code
> > >> already; first you build the exportable flat context token, and only
> > >> after you've successfully built it, do you free the gss context.
> >
> > This is fine for krb5, which can atomically export a context. As my
> > previous messages have stated, I'm unconvinced that this is possible
> > for all mechanisms.
>
> What will be the typical failure mode for an application that
> wants to export a context and can't? Is it really going to continue
> on and do something else with the context, or is it going to delete it
> and return an error? Answering that might help answer this question.
A careful application might try to inquire_context() and write in its
logs who the affected client was and what the context looked like when
the context export failed ...
:)
-Martin
Received: from ietf.org by ietf.org id aa21265; 7 Mar 97 4:16 EST
Received: from ecrc.de by ietf.org id aa21005; 7 Mar 97 4:02 EST
Received: from scorpio.ecrc.de (scorpio.ecrc.de [141.1.4.100]) by ecrc.ecrc.de (8.8.3/8.8.3/$Revision: 1.2 $) with ESMTP id KAA16620; Fri, 7 Mar 1997 10:00:13 +0100 (MET)
Received: from acrab25.ecrc.de (acrab25.ecrc.de [141.1.6.125])
by scorpio.ecrc.de (8.8.3/8.8.4/$Revision: 1.4 $) with ESMTP
id JAA02037; Fri, 7 Mar 1997 09:57:47 +0100 (MET)
Sender:ietf-request at ietf.org
From: Dave Morton <Dave.Morton at ecrc.de>
Received: (from dave at localhost) by acrab25.ecrc.de (8.8.2/8.8.2/$Revision: 1.1 $) id KAA01293; Fri, 7 Mar 1997 10:00:11 +0100 (MET)
Date: Fri, 7 Mar 1997 10:00:11 +0100 (MET)
Message-Id: <199703070900.KAA01293 at acrab25.ecrc.de>
To: karn at qualcomm.com, randy at psg.com
Subject: Re: Memphis hotel situation
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
>> The recurring IETF hotel situation is becoming completely
>> untenable. Aside from moving the IETF permanently to Las Vegas (if any
>> US city can handle a group our size, Vegas is it), does anyone have
>> any ideas to solve this problem?
>
>Vladavostok, Cape Town, Santiago, Havana, ... All beautiful cities, and we
>would solve two problems with one hack.
>
>randy
Randy - next IETF is Munich - I think we have the hotel situation
under control for the Aug. meeting.
And now let me see where I can get a room for Memphis :-)
Dave
Received: from ietf.org by ietf.org id aa28252; 7 Mar 97 9:40 EST
Received: from ietf.ietf.org by ietf.org id aa28102; 7 Mar 97 9:38 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-dnsrr-02.txt
Date: Fri, 07 Mar 1997 09:37:59 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703070938.aa28102 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 Roaming Operations Working
Group of the IETF.
Title : The Roaming Relationship (REL) Resource Record
in the DNS
Author(s) : B. Aboba
Filename : draft-ietf-roamops-dnsrr-02.txt
Pages : 15
Date : 03/06/1997
This document describes the use of the Roaming Relationship (REL) record in
the DNS for the description of roaming relationships. In the absence of DNS
security, REL resource records may be used for determining the existence of
a roaming relationship path between the local ISP and the user's home
domain, as well as the location of an appropriate accounting agent.
However, without DNS security, hierarchical authentication routing must be
used in order to validate the roaming relationship path. When DNS security
is implemented, the roaming relationship path is authenticated via digital
signatures, and as a result, additional services may be provided, such as
non-repudiation of proxied authentications and signed receipts for
accounting record transfers.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-dnsrr-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-dnsrr-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-roamops-dnsrr-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: <19970306140919.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-dnsrr-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-dnsrr-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970306140919.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28350; 7 Mar 97 9:41 EST
Received: from ietf.ietf.org by ietf.org id aa28058; 7 Mar 97 9:37 EST
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-murphy-ospf-signature-03.txt
Date: Fri, 07 Mar 1997 09:37:53 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703070937.aa28058 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : OSPF with Digital Signatures
Author(s) : S. Murphy, M. Badger, B. Wellington
Filename : draft-murphy-ospf-signature-03.txt
Pages : 32
Date : 03/06/1997
This memo describes the extensions to OSPF required to add digital
signature authentication to Link State data, and to provide a certification
mechanism for router data. Added LSA processing and key management is
detailed. A method for migration from, or co-existence with, standard
OSPF V2 is 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-murphy-ospf-signature-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-murphy-ospf-signature-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-murphy-ospf-signature-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.
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: <19970306104324.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-murphy-ospf-signature-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-murphy-ospf-signature-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970306104324.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28356; 7 Mar 97 9:41 EST
Received: from ietf.ietf.org by ietf.org id aa28101; 7 Mar 97 9:38 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-actng-01.txt
Date: Fri, 07 Mar 1997 09:38:01 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703070938.aa28101 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 Roaming Operations Working
Group of the IETF.
Title : The Accounting Problem in Roaming
Author(s) : B. Aboba
Filename : draft-ietf-roamops-actng-01.txt
Pages : 22
Date : 03/06/1997
This document describes the accounting problems that arise in the provision
of inter-provider services, such as provision of dialup roaming
capabilities. These include issues relating to standardization of
accounting record formats, and inter-provider transfers of accounting
record bundles. Work relevant to the solution of these problems are
reviewed, and recommendations are made on the direction of future
standardization work.
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-roamops-actng-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-actng-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-roamops-actng-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.
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: <19970306141529.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-actng-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-actng-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970306141529.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28355; 7 Mar 97 9:41 EST
Received: from ietf.ietf.org by ietf.org id aa28074; 7 Mar 97 9:37 EST
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-atm2TC-06.txt
Date: Fri, 07 Mar 1997 09:37:55 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703070937.aa28074 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 Textual Conventions and OBJECT-IDENTITIES
for ATM Management
Author(s) : M. Noto, E. Spiegel, K. Tesink
Filename : draft-ietf-atommib-atm2TC-06.txt
Pages : 20
Date : 03/06/1997
This memo describes Textual Conventions and OBJECT-IDENTITIES used for
managing ATM-based interfaces, devices, networks and services.
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-atm2TC-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-atm2TC-06.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-atommib-atm2TC-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.
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: <19970306135419.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-atommib-atm2TC-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-atommib-atm2TC-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970306135419.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28357; 7 Mar 97 9:41 EST
Received: from ietf.ietf.org by ietf.org id aa28042; 7 Mar 97 9:37 EST
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-stepanek-vipre-00.txt
Date: Fri, 07 Mar 1997 09:37:51 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703070937.aa28042 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : VIPRE -- Virtual Internet Packet Relay
An Encapsulation Architecture for Unidirectional Links
Author(s) : J. Stepanek, S. Schwab
Filename : draft-stepanek-vipre-00.txt
Pages : 11
Date : 03/06/1997
This memo describes a method of incorporating unidirectional links into an
IP network in a bidirectional mode by relaying encapsulated IP packets over
a bidirectional 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-stepanek-vipre-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-stepanek-vipre-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-stepanek-vipre-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: <19970306101356.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-stepanek-vipre-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-stepanek-vipre-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970306101356.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28358; 7 Mar 97 9:41 EST
Received: from ietf.ietf.org by ietf.org id aa28104; 7 Mar 97 9:38 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-nai-02.txt
Date: Fri, 07 Mar 1997 09:38:02 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703070938.aa28104 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 Roaming Operations Working
Group of the IETF.
Title : The Network Access Identifier
Author(s) : B. Aboba
Filename : draft-ietf-roamops-nai-02.txt
Pages : 5
Date : 03/06/1997
This document describes issues relating to user identification in provision
of "roaming capability" for dialup Internet users. "Roaming capability"
may be loosely defined as the ability to use any one of multiple Internet
service providers (ISPs), while maintaining a formal, customer-vendor
relationship with only one. Examples of cases where roaming capability
might be required include ISP "confederations" and ISP-provided corporate
network access support.
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-roamops-nai-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-nai-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-roamops-nai-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: <19970306141847.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-nai-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-nai-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970306141847.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28797; 7 Mar 97 9:47 EST
Received: from ietf.ietf.org by ietf.org id aa28759; 7 Mar 97 9:46 EST
To: IETF-Announce: ;
cc: ietf-ids at umich.edu
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: Best Current Practice for the Internet White Pages
Service to BCP
Reply-to: iesg at ietf.org
Date: Fri, 07 Mar 1997 09:46:53 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703070946.aa28759 at ietf.org>
The IESG has received a request from the Integrated Directory Services
Working Group to consider "Best Current Practice for the Internet White
Pages Service" <draft-ietf-ids-ds-bcp-02.txt> for the status of BCP.
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 March 20, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa28924; 7 Mar 97 9:50 EST
Received: from mercury.Sun.COM by ietf.org id aa28861; 7 Mar 97 9:48 EST
Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA21772 for <ietf at ietf.org>; Fri, 7 Mar 1997 06:44:36 -0800
Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3)
id JAA00451; Fri, 7 Mar 1997 09:45:21 -0500
Received: from maple.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4)
id JAA19011; Fri, 7 Mar 1997 09:45:23 -0500
Received: from maple by maple.East.Sun.COM (SMI-8.6/SMI-SVR4)
id JAA10197; Fri, 7 Mar 1997 09:44:33 -0500
Date: Fri, 7 Mar 1997 09:44:33 -0500 (EST)
Sender:ietf-request at ietf.org
From: Miriam Kadansky - SUN Microsystems <Miriam.Kadansky at east.sun.com>
Reply-To: Miriam Kadansky - SUN Microsystems <Miriam.Kadansky at east.sun.com>
Subject: Re: Memphis hotel situation
To: ietf at ietf.org
Message-ID: <libSDtMail.9703070944.21037.miriamk at maple/maple>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ssYz/0uCZ9SCST2MCPNjVQ==
X-Mailer: dtmail 1.1.0 CDE Version 1.1_48 SunOS 5.5.1 sun4m sparc
Source-Info: From (or Sender) name not authenticated.
How about putting more sessions out on the MBone? I know many folks
who are interested in only a few areas, and would be happy to stay
home and tune in to only those sessions.
I tried to do this once, but found it impossible because there was no
easy way to connect to the MBone from my site, and the Multicast Guide
was not published far enough in advance to figure out if my favorite
sessions were covered.
For those people who can't get on the MBone, what if some members in
major cities hosted MBone participation?
From: Randy Bush <randy at psg.com>
To: Phil Karn <karn at qualcomm.com>
Cc: ietf at ietf.org
Subject: Re: Memphis hotel situation
> The recurring IETF hotel situation is becoming completely
> untenable. Aside from moving the IETF permanently to Las Vegas (if any
> US city can handle a group our size, Vegas is it), does anyone have
> any ideas to solve this problem?
Vladavostok, Cape Town, Santiago, Havana, ... All beautiful cities, and
we
would solve two problems with one hack.
randy
Received: from ietf.org by ietf.org id aa28925; 7 Mar 97 9:50 EST
Received: from fnal.fnal.gov by ietf.org id aa28496; 7 Mar 97 9:43 EST
Received: from gungnir.fnal.gov ("port 36412"@gungnir.fnal.gov)
by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IG7QWZ9R5A0007NN at FNAL.FNAL.GOV>;
Fri, 07 Mar 1997 08:40:46 -0600
Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4)
id IAA06755; Fri, 07 Mar 1997 08:40:45 -0600
Date: Fri, 07 Mar 1997 08:40:45 -0600
Sender:ietf-request at ietf.org
From: Matt Crawford <crawdad at fnal.gov>
Subject: Re: Memphis hotel situation
In-reply-to: "06 Mar 1997 17:10:31 PST."
<"199703070110.RAA27320"@servo.qualcomm.com>
X-Orig-Sender: crawdad at gungnir.fnal.gov
To: Phil Karn <karn at qualcomm.com>
Cc: ietf at ietf.org
Message-id: <199703071440.IAA06755 at gungnir.fnal.gov>
Content-transfer-encoding: 7BIT
X-Face:
/RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$! at A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{<k&QF?d6L7o&zLqb%kXn!!]ykXMKtTiy9#20]$EKP/^Z$T]'P6,
8L#r&mH4PB<ljN,_.=iCpv#N:HIcy5t7{HV:<=g=V?^;-d,J*xkq0r
Source-Info: From (or Sender) name not authenticated.
> Aside from moving the IETF permanently to Las Vegas ...
No! No!
Received: from ietf.org by ietf.org id aa05190; 7 Mar 97 10:58 EST
Received: from Cust21.Max9.Seattle.WA.MS.UU.NET by ietf.org id aa05063;
7 Mar 97 10:53 EST
Received: from localhost (aboba at localhost) by monitor.internaut.com (8.8.5/8.6.12) with SMTP id HAA08596; Fri, 7 Mar 1997 07:47:53 -0800 (PST)
Date: Fri, 7 Mar 1997 07:47:53 -0800 (PST)
Sender:ietf-request at ietf.org
From: Bernard Aboba <aboba at monitor.internaut.com>
To: Phil Karn <karn at qualcomm.com>
cc: ietf at ietf.org
Subject: Re: Memphis hotel situation
In-Reply-To: <199703070110.RAA27320 at servo.qualcomm.com>
Message-ID: <Pine.BSI.3.95.970307074447.8577C-100000 at monitor.internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
You might try the following:
Sleepin at Court Square
40 North Front St.
Memphis, Tennessee 38103
(901)522-9700
$70/night
Radisson Hotel
185 Union AVe.
Memphis, Tennessee 38103
(901)528-1800
(800)333-3333
Received: from ietf.org by ietf.org id aa06041; 7 Mar 97 11:10 EST
Received: from ietf.ietf.org by ietf.org id aa05978; 7 Mar 97 11:08 EST
To: IETF-Announce: ;
Subject: Encapsulation
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Date: Fri, 07 Mar 1997 11:08:56 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703071108.aa05978 at ietf.org>
The IESG is extending the last-call periods for the following:
o Generic Routing Encapsulation (GRE)
<RFC1701>
o Generic Routing Encapsulation over IPv4 networks
<RFC1702>
o Generic Packet Tunneling in IPv6 Specification
<draft-ietf-ipngwg-ipv6-tunnel-07.txt>
A number of people pointed out after the IESG announced that it
had received a request to consider Generic Routing Encapsulation (RFC
1701 and RFC 1702) for the status of IETF Proposed standards that this
request could cause some level of confusion since there are already a
number of existing RFCs which describe encapsulation schemes for IPv4
and an Internet-Draft which was recently also the subject of an IETF
last-call (draft-ietf-ipngwg-ipv6-tunnel-07.txt) that describes an
encapsulation scheme to be used with IPv6.
The comment period will run for another two weeks (March 21) in order
to get comments from the IETF community about the desirability of
minimizing any confusion over what encapsulation technology or
technologies that the IETF should recommend and under what situations.
Possibilities include:
o Having multiple encapsulating protocols and let the marketplace
decide on which technology to use in which cases
o Selecting a single IPv4 encapsulation technology and a single IPv6
encapsulation technology
In addition to advice on what direction the IETF should take the IESG
is also soliciting advice about the process we should follow (one time BOF,
short lived WG, etc.).
Finally, the IESG would like to answer a question that was asked in
more than one message. Cisco Systems has explicitly disavowed any
claims of IPR relating to the technology described in RFC1701 and
RFC1702.
Received: from ietf.org by ietf.org id aa06995; 7 Mar 97 11:25 EST
Received: from dell05.cnri.reston.va.us by ietf.org id aa06740;
7 Mar 97 11:23 EST
Message-Id: <2.2.32.19970307162047.006d5884 at ietf.org>
X-Sender: mbeaulie at ietf.org
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 07 Mar 1997 11:20:47 -0500
To: Bernard Aboba <aboba at monitor.internaut.com>,
Phil Karn <karn at qualcomm.com>
Sender:ietf-request at ietf.org
From: Marcia Beaulieu <mbeaulie at ietf.org>
Subject: Re: Memphis hotel situation
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
The Radisson Hotel is also full, I am finalizing arrangements
at a hotel that is about 5 blocks away but on the trolley line,
the trolley runs every 15 to 20 minutes and drops you off about
one block from the Peabody. I will send the specifics as soon as
I receive them.
Marcia
At 07:47 AM 3/7/97 -0800, Bernard Aboba wrote:
>You might try the following:
>
>Sleepin at Court Square
>40 North Front St.
>Memphis, Tennessee 38103
>(901)522-9700
>$70/night
>
>Radisson Hotel
>185 Union AVe.
>Memphis, Tennessee 38103
>(901)528-1800
>(800)333-3333
>
>
>
Received: from ietf.org by ietf.org id aa07695; 7 Mar 97 11:39 EST
Received: from dirty.research.bell-labs.com by ietf.org id aa07557;
7 Mar 97 11:38 EST
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Fri Mar 7 11:35:13 EST 1997
Received: from sea.dnrc.bell-labs.com ([135.180.144.10]) by research; Fri Mar 7 11:32:55 EST 1997
Received: from sea (localhost [127.0.0.1]) by sea.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id LAA17873 for <ietf at ietf.org>; Fri, 7 Mar 1997 11:30:37 -0500 (EST)
X-Orig-Sender: hgs at dnrc.bell-labs.com
Message-ID: <332042AD.5128 at cs.columbia.edu>
Date: Fri, 07 Mar 1997 11:30:37 -0500
Sender:ietf-request at ietf.org
From: "Henning Schulzrinne (BL)" <hgs at cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.4 sun4m)
MIME-Version: 1.0
To: ietf at ietf.org
Subject: Memphis hotel/Mbone
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Unfortunately, the audio quality of the Mbone is too unpredictable (or,
in many places, predictably unusable) that you could replace travel.
Given the will, it would seem fairly easy to arrange standard
telephone-conferencing gear such as the PolyCom, with hookup to the
house audio system. I'd gladly pay long-distance by the minute to
actually understand what's being said (and maybe even contribute and be
understood). Video/wb for slides over Mbone works just fine. (By special
effort of the secretariat, this was done once in San Jose,
unfortunately, the audio setup wasn't the greatest).
Henning
Received: from cnri by ietf.org id aa10319; 7 Mar 97 12:16 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11899;
7 Mar 97 12:16 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <OAA26432 at pad-thai.cam.ov.com>; Fri, 7 Mar 1997 14:53:17 GMT
Message-Id: <9703071448.AA12885 at us1rmc.bb.dec.com>
Date: Fri, 7 Mar 97 09:48:15 EST
From: "John Wray, Digital DPE, (508) 486-5210 07-Mar-1997 0911" <wray at tuxedo.enet.dec.com>
To: dennis.glatting at plaintalk.bellevue.wa.us
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, dennis.glatting at plaintalk.bellevue.wa.us
Subject: Re: Comments solicited re negotiated mechanism action
Precedence: bulk
Dennis writes:
>I vote for snego, as it stands, to advance to informational or
>experimental and another approach pursued. Perhaps too we
>should start on GSS-APIv3, not backward compatible with v1 and
>v2, and addresses GSS-APIv2's shortcomings, such as nego,
>configuration, thread safety, single sign-on, etc.
Why do you think GSSAPI V2 would be a poor base for a
GSSAPI that includes these features?
GSSAPI currently doesn't address configuration or single sign-on
(or sign-on at all, come to that), but I don't see anything in the
current specs that would make it awkward to add these features. I think
we really should start work on support for pluggable mechanisms - a GSS-SPI -
and this would probably include some configuration stuff (although I'm not
sure how much of configuration needs to be standardized, rather than left
platform-specific).
SNEGO or a protected version thereof would seem to work OK as methods
of adding negotiation, and since in many environments negotiation
isn't wanted I'm not convinced that it should be an integral part of
GSSAPI. The only issues I have with SNEGO are to do with the lack of
protection during the negotiation, not the way that it's bolted onto
GSSAPI. The textual description of the GSSAPI specs could perhaps be
more negotiation-friendly (for example, the routine description for
gss_init_sec_context() could explicitly say that the actual_mech
parameter doesn't have to be the same as the input mech_type parameter, and
use a negotiation mechanism mech_type as an example, where the eventual
actual_mech parameter would indicate the chosen mechanism, not the negotiation
mechanism). I can imagine all sorts of ways an application might want
to "tweak" the negotiation process, but I don't see why any of these couldn't
be added on via additional calls to annotate the credential prior to calling
gss_init_sec_context() - i.e. done as extensions, rather than incompatible
changes.
As far as I know, the V2 spec doesn't contain any intrinsic threading problems,
although specific implementations may not necessarily be thread-safe. What
threading issues do you have with the current specs? We ought to address them
in V2 - threads aren't "exotic" any more.
John
Received: from ietf.org by ietf.org id aa11725; 7 Mar 97 12:52 EST
Received: from dot.netrex.net by ietf.org id aa11543; 7 Mar 97 12:48 EST
Received: from rgm3 (nsn1-gw5-xl1.netrex.com [206.253.228.11]) by dot.netrex.net (8.8.5/8.7.3) with SMTP id MAA21256; Fri, 7 Mar 1997 12:46:07 -0500 (EST)
Message-Id: <3.0.1.32.19970307124340.009fea00 at dilbert.is.chrysler.com>
Reply-To: rgm3 at chrysler.com
X-Sender: rgm3 at dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 07 Mar 1997 12:43:40 -0500
To: "Henning Schulzrinne (BL)" <hgs at cs.columbia.edu>, ietf at ietf.org
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: Memphis hotel/Mbone
In-Reply-To: <332042AD.5128 at cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
At 11:30 AM 3/7/97 -0500, Henning Schulzrinne (BL) wrote:
>Video/wb for slides over Mbone works just fine. (By special
>effort of the secretariat, this was done once in San Jose,
>unfortunately, the audio setup wasn't the greatest).
As I recall, it was by special effort of one of our hosts, Xerox that
supplied the wg systems. Others did the back-end systems.
They were neat.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.org by ietf.org id aa12605; 7 Mar 97 13:10 EST
Received: from hq.barrnet.net by ietf.org id aa12501; 7 Mar 97 13:07 EST
Received: (from vaf at localhost) by hq.barrnet.net (8.7.5/HQ-Len-1.1) id KAA22726; Fri, 7 Mar 1997 10:05:24 -0800 (PST)
Date: Fri, 7 Mar 97 10:05:24 PST
Sender:ietf-request at ietf.org
From: Vince Fuller <vaf at wr.bbnplanet.com>
To: Randy Bush <randy at psg.com>
Cc: Phil Karn <karn at qualcomm.com>, ietf at ietf.org
Phone: (415) 528-7227
USMail: 3801 East Bayshore Rd, Palo Alto, CA, 94303
Subject: Re: Memphis hotel situation
In-Reply-To: Your message of Thu, 6 Mar 97 18:01 PST
Message-ID: <CMM.0.90.2.857757924.vaf at hq.barrnet.net>
Source-Info: From (or Sender) name not authenticated.
Vladavostok, Cape Town, Santiago, Havana, ... All beautiful cities, and we
would solve two problems with one hack.
Well, if there is ever a plan to have another IETF in Northern California,
I'd suggest, mostly-seriously, South Lake Tahoe. There are thousands of
hotel rooms because of the casinos, it's far enough away from Silicon Valley
to reduce the "drop-in random factor", it's within an hour of an airport
(Reno, albeit not the best-connected), and if you schedule it away from the
peak ski season the "boondoggle factor" and crowds aren't too bad. Much nicer
than Vegas with some of the benefits (i.e. large hotels).
Following Interop's lead, perhaps Atlanta in an east-coast choice - lots
of hotels, conference facilities, and a big airport. Schedule it in July or
August and the humidity will keep the crowds away...
--Vince
Received: from cnri by ietf.org id aa15237; 7 Mar 97 14:12 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14234;
7 Mar 97 14:12 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA03501 at pad-thai.cam.ov.com>; Fri, 7 Mar 1997 17:38:10 GMT
Message-Id: <199703071737.MAA04437 at gza-client1.cam.ov.com>
To: wray at tuxedo.enet.dec.com
Cc: cat-ietf at mit.edu
Subject: Re: Comments solicited re negotiated mechanism action
Date: Fri, 07 Mar 1997 12:37:53 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
John writes, excerpting:
>The textual description of the GSSAPI specs could perhaps be
>more negotiation-friendly (for example, the routine description for
>gss_init_sec_context() could explicitly say that the actual_mech
>parameter doesn't have to be the same as the input mech_type
>parameter, and use a negotiation mechanism mech_type as an example,
>where the eventual actual_mech parameter would indicate the chosen
>mechanism, not the negotiation mechanism).
I thought that RFC-2078 explicitly covered this; I checked and it
does. On page 39 (deep into the discussion of
GSS_Init_sec_context()), is the following text:
> The returned mech_type value indicates the specific mechanism
> employed on the context, is valid only along with major_status
> GSS_S_COMPLETE, and will never indicate the value for "default".
> Note that, for the case of certain mechanisms which themselves
> perform negotiation, the returned mech_type result may indicate
> selection of a mechanism identified by an OID different than that
> passed in the input mech_type argument.
--jl
Received: from ietf.org by ietf.org id aa16166; 7 Mar 97 14:50 EST
Received: from core.IConNet.NET by ietf.org id aa15405; 7 Mar 97 14:20 EST
Received: from localhost (brisco at localhost)
by fs.IConNet.NET (8.8.5/8.8.5) with SMTP id OAA07819;
Fri, 7 Mar 1997 14:18:19 -0500 (EST)
Date: Fri, 7 Mar 1997 14:18:18 -0500 (EST)
Sender:ietf-request at ietf.org
From: "T.P.Brisco" <brisco at iconnet.net>
To: "Henning Schulzrinne (BL)" <hgs at cs.columbia.edu>
cc: ietf at ietf.org
Subject: Re: Memphis hotel/Mbone
In-Reply-To: <332042AD.5128 at cs.columbia.edu>
Message-ID: <Pine.GSO.3.92.970307141145.7333A-100000 at fs.IConNet.NET>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
One of the groups that I do work with a lot has resorted to using
a "broadcast" 800 number. The 800 number (from the committee's
perspective) is "outgoing only" (i.e. I can't talk back) - I can patch
in/out at my leasure - and get all the quality that my telephone will
bring me :-)
Has the group considered a (cheap) 900 number in such an
arrangement?
Tp
On Fri, 7 Mar 1997, Henning Schulzrinne (BL) wrote:
> Unfortunately, the audio quality of the Mbone is too unpredictable (or,
> in many places, predictably unusable) that you could replace travel.
> Given the will, it would seem fairly easy to arrange standard
> telephone-conferencing gear such as the PolyCom, with hookup to the
> house audio system. I'd gladly pay long-distance by the minute to
> actually understand what's being said (and maybe even contribute and be
> understood). Video/wb for slides over Mbone works just fine. (By special
> effort of the secretariat, this was done once in San Jose,
> unfortunately, the audio setup wasn't the greatest).
>
> Henning
>
Received: from cnri by ietf.org id aa16302; 7 Mar 97 14:54 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15150;
7 Mar 97 14:54 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA05210 at pad-thai.cam.ov.com>; Fri, 7 Mar 1997 18:22:15 GMT
Date: Fri, 7 Mar 1997 13:19:34 -0500
Message-Id: <9703071819.AA08475 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: schemers at stanford.edu
Cc: Marc Horowitz <marc at cygnus.com>, Theodre Ts'o <tytso at lurch.mit.edu>,
wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
In-Reply-To: schemers at stanford.edu's message of Thu, 6 Mar 1997 14:51:07 -0800
(PST), <199703062251.OAA19406 at tree2.Stanford.EDU>
Subject: Re: gss_export_sec_context()
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Thu, 6 Mar 1997 14:51:07 -0800 (PST)
From: schemers at stanford.edu
What will be the typical failure mode for an application that
wants to export a context and can't? Is it really going to continue
on and do something else with the context, or is it going to delete it
and return an error? Answering that might help answer this question.
Assuming that the application links (I think an implementation has to
supply export_context even if it's not supported, although there may be
some disagreement on this issue), I'd assume that likely failure modes
would be things like memory allocation failures.
- Ted
Received: from cnri by ietf.org id aa17056; 7 Mar 97 15:17 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15621;
7 Mar 97 15:17 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA02327 at pad-thai.cam.ov.com>; Fri, 7 Mar 1997 17:08:25 GMT
Message-Id: <199703071708.JAA10781 at imo.plaintalk.bellevue.wa.us>
Content-Type: text/plain
Mime-Version: 1.0 (NeXT Mail 3.3 v118.2)
From: Dennis Glatting <dennis.glatting at plaintalk.bellevue.wa.us>
Date: Fri, 7 Mar 97 09:08:05 -0800
To: "John Wray, Digital DPE, (508) 486-5210 07-Mar-1997 0911" <wray at tuxedo.enet.dec.com>,
cat-ietf at mit.edu
Subject: Re: Comments solicited re negotiated mechanism action
Reply-To: dennis.glatting at plaintalk.bellevue.wa.us
References: <9703071448.AA12885 at us1rmc.bb.dec.com>
Precedence: bulk
> From: Dennis Glatting <dennisg>
> Date: Fri, 7 Mar 97 08:49:44 -0800
>
> > From: "John Wray, Digital DPE, (508) 486-5210 07-Mar-1997
> > 0911" <wray at tuxedo.ENET.dec.com>
> > Date: Fri, 7 Mar 97 09:48:15 EST
> >
> > Dennis writes:
> >
> [ snip ]
>
> My thoughts regarding configuration are: the default mech;
> preference mech order for nego; preference QOP order and
> restricted QOP usage per mech; advertised mech set for nego vs
> available mech set; restricte name type per mech; preferred
> name type per mech and across the mech set; mech preferences
> such as replay detection; then underlying mech specific
> options such as "Kerberos: use a memory based replay cache".
>
Asa an aside, I believe it would be beneficial to the community
if the Kerberos configuration syntax were standardized too.
-dpg
Received: from cnri by ietf.org id aa18199; 7 Mar 97 15:58 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16523;
7 Mar 97 15:59 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA05453 at pad-thai.cam.ov.com>; Fri, 7 Mar 1997 18:26:11 GMT
Date: Fri, 7 Mar 1997 13:26:06 -0500
Message-Id: <9703071826.AA08487 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: "John Wray, Digital DPE, 486-5210 07-Mar-1997 0911" <wray at tuxedo.enet.dec.com>
Cc: cat-ietf at mit.edu
In-Reply-To: John Wray, Digital DPE, (508) 486-5210 07-Mar-1997 0911's message
of Fri, 7 Mar 97 09:48:15 EST, <9703071448.AA12885 at us1rmc.bb.dec.com>
Subject: Re: Comments solicited re negotiated mechanism action
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Fri, 7 Mar 97 09:48:15 EST
From: "John Wray, Digital DPE, (508) 486-5210 07-Mar-1997 0911" <wray at tuxedo.ENET.dec.com>
As far as I know, the V2 spec doesn't contain any intrinsic threading
problems, although specific implementations may not necessarily be
thread-safe. What threading issues do you have with the current
specs? We ought to address them in V2 - threads aren't "exotic" any
more.
The main complaints which I've heard is that GSSAPI doesn't have a
"startup" and "shutdown" function, and that it doesn't have a library
context variable which is passed into each function. This means that if
the library needs to keep any state that needs to be accessed by
functions which don't take a security context, the state has to be
stored in a static variable. For some restricted OS's emanating from
Redmond, WA, this can cause some problems, although generally there are
ways of working around them.
The other approach of fixing threading would be to add functions which
allow an application to register and deregister locking primitives to
work with an arbitrary threading infrastructure. (Alternatively, you
could make the implementation work with one and exactly thread library
without making any changes to the API; this requires that all
applications using that particular GSSAPI mechanism would have to use
that thread library.)
None of these approaches is particularly fun nor simple, but then again,
neither is threading. :-/
- Ted
Received: from cnri by ietf.org id aa18475; 7 Mar 97 16:08 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16831;
7 Mar 97 16:09 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <QAA01534 at pad-thai.cam.ov.com>; Fri, 7 Mar 1997 16:50:11 GMT
Message-Id: <199703071649.IAA10762 at imo.plaintalk.bellevue.wa.us>
Content-Type: text/plain
Mime-Version: 1.0 (NeXT Mail 3.3 v118.2)
From: Dennis Glatting <dennis.glatting at plaintalk.bellevue.wa.us>
Date: Fri, 7 Mar 97 08:49:44 -0800
To: "John Wray, Digital DPE, (508) 486-5210 07-Mar-1997 0911" <wray at tuxedo.enet.dec.com>
Subject: Re: Comments solicited re negotiated mechanism action
Cc: cat-ietf at mit.edu
Reply-To: dennis.glatting at plaintalk.bellevue.wa.us
References: <9703071448.AA12885 at us1rmc.bb.dec.com>
Precedence: bulk
> From: "John Wray, Digital DPE, (508) 486-5210 07-Mar-1997
> 0911" <wray at tuxedo.ENET.dec.com>
> Date: Fri, 7 Mar 97 09:48:15 EST
>
> Dennis writes:
>
> >I vote for snego, as it stands, to advance to informational or
> >experimental and another approach pursued. Perhaps too we
> >should start on GSS-APIv3, not backward compatible with v1 and
> >v2, and addresses GSS-APIv2's shortcomings, such as nego,
> >configuration, thread safety, single sign-on, etc.
>
> Why do you think GSSAPI V2 would be a poor base for a
> GSSAPI that includes these features?
>
I didn't mean to imply it wasn't. I mean v3 need not resemble v2
and nothing in v2 should be considered sacred.
> GSSAPI currently doesn't address configuration or single
> sign-on (or sign-on at all, come to that), but I don't see
> anything in the current specs that would make it awkward to add
> these features. I think we really should start work on support
> for pluggable mechanisms - a GSS-SPI - and this would probably
> include some configuration stuff (although I'm not sure how
> much of configuration needs to be standardized, rather than
> left platform-specific).
>
My thoughts regarding configuration are: the default mech;
preference mech order for nego; preference QOP order and
restricted QOP usage per mech; advertised mech set for nego vs
available mech set; restricte name type per mech; preferred
name type per mech and across the mech set; mech preferences
such as replay detection; then underlying mech specific
options such as "Kerberos: use a memory based replay cache".
[snip ]
> As far as I know, the V2 spec doesn't contain any intrinsic
> threading problems, although specific implementations may
> not necessarily be thread-safe. What threading issues do you
> have with the current specs? We ought to address them in V2 -
> threads aren't "exotic" any more.
>
An environment context passed to each function. An underlying
mech, for example, could store a per-thread pRNG state within
the context. GSS-API and mechanisms could store
traditionally static data, such as the default Kerberos
realm, within the context too.
-dpg
Received: from ietf.org by ietf.org id aa19971; 7 Mar 97 16:53 EST
Received: from hail.ncr.disa.mil by ietf.org id aa19803; 7 Mar 97 16:48 EST
Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id QAA14590; Fri, 7 Mar 1997 16:43:36 -0500 (EST)
Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01)
id AA857781712; Fri, 07 Mar 97 16:28:43 EST
Date: Fri, 07 Mar 97 16:28:43 EST
Sender:ietf-request at ietf.org
From: Bill Flanigan <flanigab at ncr.disa.mil>
Message-Id: <9702078577.AA857781712 at ncr.disa.mil>
To: Vince Fuller <vaf at wr.bbnplanet.com>
Cc: ietf at ietf.org
Subject: Drop-In Random Factor (Was: Re[2]: Memphis hotel situation)
Source-Info: From (or Sender) name not authenticated.
Vince,
If you hold all meetings in, say, Europe (and outside the US), you
can really keep the "drop-in random factor" low. Munich is beautiful;
so is Rome, Venice, Paris, Stockholm, etc. I personally prefer the
Caribbean, especially Saba (in the East) and the Caiman Islands (in
the West). And in the future there will be Mars and the moons of
Jupiter.
Bill Flanigan
______________________________ Reply Separator _________________________________
Subject: Re: Memphis hotel situation
Author: Vince Fuller <vaf at wr.bbnplanet.com> at smtp
Date: 3/7/97 10:05 AM
Vladavostok, Cape Town, Santiago, Havana, ... All beautiful cities, and we
would solve two problems with one hack.
Well, if there is ever a plan to have another IETF in Northern California,
I'd suggest, mostly-seriously, South Lake Tahoe. There are thousands of
hotel rooms because of the casinos, it's far enough away from Silicon Valley
to reduce the "", it's within an hour of an airport
(Reno, albeit not the best-connected), and if you schedule it away from the
peak ski season the "boondoggle factor" and crowds aren't too bad. Much nicer
than Vegas with some of the benefits (i.e. large hotels).
Following Interop's lead, perhaps Atlanta in an east-coast choice - lots
of hotels, conference facilities, and a big airport. Schedule it in July or
August and the humidity will keep the crowds away...
--Vince
Received: from ietf.org by ietf.org id aa20121; 7 Mar 97 16:55 EST
Received: from hail.ncr.disa.mil by ietf.org id aa20029; 7 Mar 97 16:55 EST
Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id QAA14914; Fri, 7 Mar 1997 16:50:45 -0500 (EST)
Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01)
id AA857782316; Fri, 07 Mar 97 16:50:20 EST
Date: Fri, 07 Mar 97 16:50:20 EST
Sender:ietf-request at ietf.org
From: Bill Flanigan <flanigab at ncr.disa.mil>
Message-Id: <9702078577.AA857782316 at ncr.disa.mil>
To: Marcia Beaulieu <mbeaulie at ietf.org>
Cc: ietf at ietf.org
Return-Receipt-To: flanigab at ncr.disa.mil
Subject: Re[2]: Memphis hotel situation
Source-Info: From (or Sender) name not authenticated.
Hello Marcia,
Here's part of an email I sent out to the list on 27 Feb that might
help.
-------------
1. Recommend you get the AAA Tour Book for Tennessee--it list
and rates about forty in "Greater "Memphis."
2. List for downtown (all have 901 area code):
a. Best Western (two diamonds) 948-9005;
b. Comfort Inn (three) 526-0583;
c. Days Inn (two) 527-4100;
d. Holiday Inn (three) 527-7300;
e. Another Holiday Inn (three) 525-5491; and
f. Radison (three) 528-1800.
3. Rack rates for the above range from $50 to $109 before AAA
(or other) discounts.
-------------
Bill Flanigan
______________________________ Reply Separator _________________________________
Subject: Re: Memphis hotel situation
Author: Marcia Beaulieu <mbeaulie at ietf.org> at smtp
Date: 3/7/97 11:27 AM
The Radisson Hotel is also full, I am finalizing arrangements
at a hotel that is about 5 blocks away but on the trolley line,
the trolley runs every 15 to 20 minutes and drops you off about
one block from the Peabody. I will send the specifics as soon as
I receive them.
Marcia
Received: from ietf.org by ietf.org id aa21653; 7 Mar 97 17:15 EST
Received: from hq.barrnet.net by ietf.org id aa21565; 7 Mar 97 17:13 EST
Received: (from vaf at localhost) by hq.barrnet.net (8.7.5/HQ-Len-1.1) id OAA27309; Fri, 7 Mar 1997 14:11:03 -0800 (PST)
Date: Fri, 7 Mar 97 14:11:03 PST
Sender:ietf-request at ietf.org
From: Vince Fuller <vaf at wr.bbnplanet.com>
To: Bill Flanigan <flanigab at ncr.disa.mil>
Cc: ietf at ietf.org
Phone: (415) 528-7227
USMail: 3801 East Bayshore Rd, Palo Alto, CA, 94303
Subject: Re: Drop-In Random Factor (Was: Re[2]: Memphis hotel situation)
In-Reply-To: Your message of Fri, 07 Mar 97 16:28:43 EST
Message-ID: <CMM.0.90.2.857772663.vaf at hq.barrnet.net>
Source-Info: From (or Sender) name not authenticated.
If you hold all meetings in, say, Europe (and outside the US), you
can really keep the "drop-in random factor" low. Munich is beautiful;
so is Rome, Venice, Paris, Stockholm, etc. I personally prefer the
Caribbean, especially Saba (in the East) and the Caiman Islands (in
the West). And in the future there will be Mars and the moons of
Jupiter.
I'm not sure if I should interpret this note as sarcastic or serious, so I
will risk taking some bait and answer it. Randy's note addressed the same
issue: holding the IETF in off-the-beaten-path locations would certainly
cut down on over-crowding. But there has to be some balance - I'm a big
fan of Grand Cayman, too (been there twice, diving was awesome, would love
to go again, especially on someone else's dime), but I suspect that my, and
others' management would look askance at having meetings in such nice,
expensive locations.
I tossed South Lake Tahoe into the ring because it is the sort of place that
has some characteristics that would be good in a IETF location:
- not a hideous place to be
- not too far from a major airport
- lots of hotel space at a range of prices
- close, but not too close, to high density of Internet geeks
The last of these is significant - the 3-4 hour drive from the Bay Area is
close enough to be practical for those who are seious about participation
but is also far enough to discourage random drop-ins. San Francisco/San Jose,
Boston, and DC are three examples of places which fail this last test - it
is just too easy and too inviting for non-participant spectators to show up
if the IETF is held in such a place.
--Vince
Received: from ietf.org by ietf.org id aa22279; 7 Mar 97 17:22 EST
Received: from cnri by ietf.org id aa22229; 7 Mar 97 17:21 EST
Received: from [208.1.117.130] by CNRI.Reston.VA.US id aa18269;
7 Mar 97 17:21 EST
Received: from legacy.lgcy.com ([207.14.219.48]) by alberta.sallynet.com (8.8.3/8.7.3) with SMTP id LAA03936; Fri, 7 Mar 1997 11:57:41 -0500 (EST)
Date: Fri, 7 Mar 1997 11:57:41 -0500 (EST)
Message-Id: <199703071657.LAA03936 at alberta.sallynet.com>
Comments: Authenticated sender is <mc at mail.scottallen.com>
Sender:ietf-request at ietf.org
From: "." <williams at lgcy.com>
To: you at alberta.sallynet.com
Subject: All Aboard!!
X-mailer: Floodgate Pro 5.0
Source-Info: From (or Sender) name not authenticated.
Four days and nights aboard a private yacht in the caribean
for $262.50???? includes meals and diving!!! Check us out at
http://www.lgcy.com/williams/caribean-cruise.html or E-mail williams at lgcy.com
Received: from cnri by ietf.org id aa10152; 8 Mar 97 2:34 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa02656;
8 Mar 97 2:34 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <GAA29652 at pad-thai.cam.ov.com>; Sat, 8 Mar 1997 06:25:32 GMT
Date: Sat, 8 Mar 1997 01:22:56 -0500 (EST)
From: Rich Salz <rsalz at osf.org>
Message-Id: <199703080622.BAA28241 at sulphur.osf.org>
To: tytso at mit.edu, wray at tuxedo.enet.dec.com
Subject: Re: Comments solicited re negotiated mechanism action
Cc: cat-ietf at mit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
>context variable which is passed into each function. This means that if
>the library needs to keep any state that needs to be accessed by
>functions which don't take a security context, the state has to be
>stored in a static variable. For some restricted OS's emanating from
>Redmond, WA, this can cause some problems, although generally there are
>ways of working around them.
Why isn't thread-local-storage/thread-specific-data acceptable?
Yes, it would probably bind a particular GSSAPI implementation to
a particular threads package, but I don't see that as onerous:
How many OS's, where you wouldn't have GSSAPI source available to
port, support more than one threads library?
As for "Redmond" are you talking about the problems with Windows
DLL's and static data, or something else? (There's really no need
to be oblique, is there?)
/r$
Received: from cnri by ietf.org id aa21150; 8 Mar 97 15:48 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11452;
8 Mar 97 15:48 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA21461 at pad-thai.cam.ov.com>; Sat, 8 Mar 1997 18:51:11 GMT
Message-Id: <m0w3RCG-0000fMC at ermail02.btx.dtag.de>
Date: Sat, 8 Mar 97 19:49 +0100
From: Scherer Annette <Annette.Scherer at t-online.de>
X-Sender: 0957172051-0001 at t-online.de (Annette Scherer)
Subject: GSS-API
To: cat-ietf at mit.edu
Precedence: bulk
Dear Ladies and Gentlemen,
I have to write a paper about WWW-security. One chapter will refer to GSS-API.
Is there any paper which gives a good overview about the GSS-API but is shorter
then the RFC or draft?
Especially I have following questions:
How does it work
Which interfaces does it provide
How can I couple it with applications and protocols
With which protocols does it work
Which advantages does it provide
What are the diffrences between RFC and draft
Thank you for your answers
Annette Scherer
Fernuniversitaet Hagen
annette.scherer at t-online.de
Received: from ietf.org by ietf.org id aa15573; 9 Mar 97 17:51 EST
Received: from THOR.INNOSOFT.COM by ietf.org id aa15211; 9 Mar 97 17:32 EST
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694)
id <01IG95SCDKG08WVYSE at INNOSOFT.COM> for ietf at ietf.org; Sun,
9 Mar 1997 14:29:04 PST
Date: Sun, 09 Mar 1997 14:03:02 -0800 (PST)
Sender:ietf-request at ietf.org
From: Ned Freed <Ned.Freed at innosoft.com>
Subject: Re: Memphis hotel situation
In-reply-to: "Your message dated Thu, 06 Mar 1997 17:10:31 -0800 (PST)"
<199703070110.RAA27320 at servo.qualcomm.com>
To: Phil Karn <karn at qualcomm.com>
Cc: ietf at ietf.org
Message-id: <01IGAVNIF5CG8WVYSE at INNOSOFT.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
> Well, the Peabody, Holiday Inn Select and Holiday Inn Crowne Plaza are all
> completely sold out for the week of the IETF. Anybody have any alternates?
> The recurring IETF hotel situation is becoming completely
> untenable. Aside from moving the IETF permanently to Las Vegas (if any
> US city can handle a group our size, Vegas is it), does anyone have
> any ideas to solve this problem?
Actually lots of facilities can handle a group as small as the IETF still is.
I've attended conferences with attendance double or even quadruple that of the
IETF and with networking needs comparable to those of the IETF in Atlanta,
Anaheim, New Orleans, Cincinnati, to name but four in the US alone, and found
all of them to be quite reasonable. And more to the point, none of them have
suffered from the problems the IETF meetings now seem to encounter with a fair
amount of regularity.
Frankly, the IETF isn't all that large, nor are its needs all that special, in
this day and age. The only real issues here are planning for the numbers we all
know have to be accomodated plus having the experience, contacts, and expertise
to arrange it all. And much as I admire the hard work that has been done
to bring off past IETFs, I do agree that there's a serious problem here in
need of fixing.
Ned
Received: from ietf.org by ietf.org id aa17600; 9 Mar 97 18:39 EST
Received: from mailhost.ipsilon.com by ietf.org id aa17035; 9 Mar 97 18:37 EST
Received: from red.ipsilon.com (red.Ipsilon.COM [205.226.1.58]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id PAA20591; Sun, 9 Mar 1997 15:34:34 -0800
Received: from red.ipsilon.com by red.ipsilon.com (8.6.12) id PAA05643; Sun, 9 Mar 1997 15:34:38 -0800
Message-Id: <199703092334.PAA05643 at red.ipsilon.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Ned Freed <Ned.Freed at innosoft.com>
cc: Phil Karn <karn at qualcomm.com>, ietf at ietf.org
Subject: Re: Memphis hotel situation
In-reply-to: Your message of "Sun, 09 Mar 1997 14:03:02 PST."
<01IGAVNIF5CG8WVYSE at INNOSOFT.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 09 Mar 1997 15:34:37 -0800
Sender:ietf-request at ietf.org
From: Greg Minshall <minshall at ipsilon.com>
Source-Info: From (or Sender) name not authenticated.
Ned, et al,
> The only real issues here are planning for the numbers we all
> know have to be accomodated plus having the experience, contacts, and expertise
> to arrange it all. And much as I admire the hard work that has been done
> to bring off past IETFs, I do agree that there's a serious problem here in
> need of fixing.
In fairness to the secretariat, which does the job of scheduling things (as i
understand the situation), it is probably the case that most other groups have
more predictable numbers of attendees and aren't experiencing the exponential
(well...) growth that the IETF is.
As i understand things, arrangements are made a few years in advance.
This isn't to say there isn't a problem (there is). And it isn't to say that
the secretariat is, in fact, doing everything possible to deal with the
problem (i have no knowledge on that one way or the other). It's just to say
that this growth thing hits us in lots of ways, one of which is that
"experience, contacts, and expertise" with a stable sized meeting may not be
enough!
Greg
Received: from cnri by ietf.org id aa01791; 10 Mar 97 3:59 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa03575;
10 Mar 97 3:59 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <HAA29070 at pad-thai.cam.ov.com>; Mon, 10 Mar 1997 07:31:18 GMT
Message-Id: <3323B8B8.658B at math.ethz.ch>
Date: Mon, 10 Mar 1997 08:31:04 +0100
From: Carlos De Sousa <desousa at math.ethz.ch>
Organization: ETH - Zuerich, Switzerland
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: cat-ietf at mit.edu
Subject: (no subject)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
unsubscribe
Thank you
Received: from ietf.org by ietf.org id aa06735; 10 Mar 97 9:50 EST
Received: from bugs_bunny.columbia.sparta.com by ietf.org id aa06507;
10 Mar 97 9:42 EST
Received: from katahdin.columbia.sparta.com by columbia.sparta.com (4.1/cfm-7-21-95)
id AA02492; Mon, 10 Mar 97 09:39:28 EST
Received: by katahdin.columbia.sparta.com (5.61/SMI-4.1)
id AA04923; Mon, 10 Mar 97 09:39:26 -0500
Sender:ietf-request at ietf.org
From: Howard Weiss <hsw at columbia.sparta.com>
Message-Id: <9703101439.AA04923 at katahdin.columbia.sparta.com>
Subject: Re: Memphis hotel situation
To: Ned Freed <Ned.Freed at innosoft.com>
Date: Mon, 10 Mar 1997 09:39:25 -0500 (EST)
Cc: karn at qualcomm.com, ietf at ietf.org
In-Reply-To: <01IGAVNIF5CG8WVYSE at INNOSOFT.COM> from "Ned Freed" at Mar 9, 97 02:03:02 pm
Organization: SPARTA Inc. (Secure Systems Engineering Division)
Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046
Phone: (410) 381-9400 x201
Fax: (410) 381-5559
X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2378
Source-Info: From (or Sender) name not authenticated.
>
> > Well, the Peabody, Holiday Inn Select and Holiday Inn Crowne Plaza are all
> > completely sold out for the week of the IETF. Anybody have any alternates?
>
> > The recurring IETF hotel situation is becoming completely
> > untenable. Aside from moving the IETF permanently to Las Vegas (if any
> > US city can handle a group our size, Vegas is it), does anyone have
> > any ideas to solve this problem?
>
> Actually lots of facilities can handle a group as small as the IETF still is.
> I've attended conferences with attendance double or even quadruple that of the
> IETF and with networking needs comparable to those of the IETF in Atlanta,
> Anaheim, New Orleans, Cincinnati, to name but four in the US alone, and found
> all of them to be quite reasonable. And more to the point, none of them have
> suffered from the problems the IETF meetings now seem to encounter with a fair
> amount of regularity.
>
> Frankly, the IETF isn't all that large, nor are its needs all that special, in
> this day and age. The only real issues here are planning for the numbers we all
> know have to be accomodated plus having the experience, contacts, and expertise
> to arrange it all. And much as I admire the hard work that has been done
> to bring off past IETFs, I do agree that there's a serious problem here in
> need of fixing.
>
> Ned
>
Indeed, the National Information Systems Security Conference (NISSC)
(formally, the National Computer Security Conference) has had
approximately 2000 attendees for years. Its held at the Baltimore
Convention Center every October and over 600 hotel rooms in downtown
Baltimore and near the Baltimore-Washington International (BWI)
Airport are held in reserve. Certainly, there are lots of "drop-in"
attendees from the Baltimore-Washington corrider, but nevertheless,
this is no different from the San Jose venue for the IETF.
Howie
--
___________________________________________________________________
| |
|Howard Weiss phone (410) 381-9400 x201 |
|SPARTA, Inc. (301) 621-8145 x201 (DC)|
|9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 |
|Columbia, MD 21046 email: hsw at columbia.sparta.com|
|___________________________________________________________________|
Received: from ietf.org by ietf.org id aa07408; 10 Mar 97 9:59 EST
Received: from ietf.ietf.org by ietf.org id aa06904; 10 Mar 97 9:52 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: madman 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-madman-dsa-mib-1-03.txt
Date: Mon, 10 Mar 1997 09:52:58 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703100952.aa06904 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail and Directory
Management Working Group of the IETF.
Title : LDAP/CLDAP/X.500 Directory Services Monitoring MIB
Author(s) : G. Mansfield, S. Kille
Filename : draft-ietf-madman-dsa-mib-1-03.txt
Pages : 21
Date : 03/07/1997
This document defines a portion of the Management Information
Base (MIB). It defines the MIB for monitoring Directory Services.
This MIB will be used in conjunction with the APPLICATION-MIB
for monitoring Directory Servers (DS)s.
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-madman-dsa-mib-1-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-madman-dsa-mib-1-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-madman-dsa-mib-1-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.
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: <19970307100815.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-madman-dsa-mib-1-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-madman-dsa-mib-1-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970307100815.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07405; 10 Mar 97 9:59 EST
Received: from ietf.ietf.org by ietf.org id aa07025; 10 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ediint at imc.org
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-ediint-as1-03.txt
Date: Mon, 10 Mar 1997 09:53:35 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703100953.aa07025 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 Electronic Data
Interchange-Internet Integration Working Group of the IETF.
Title : MIME-based Secure EDI
Author(s) : M. Jansson, C. Shih, R. Drummond
Filename : draft-ietf-ediint-as1-03.txt
Pages : 17
Date : 03/07/1997
This document describes how to securely exchange EDI documents using MIME
and public key cryptography.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ediint-as1-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ediint-as1-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-ediint-as1-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.
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: <19970310094454.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ediint-as1-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ediint-as1-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310094454.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07413; 10 Mar 97 9:59 EST
Received: from ietf.ietf.org by ietf.org id aa06924; 10 Mar 97 9:53 EST
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-07.txt
Date: Mon, 10 Mar 1997 09:53:06 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703100953.aa06924 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
Filename : draft-ietf-idmr-cbt-spec-07.txt
Pages : 27
Date : 03/07/1997
This document describes the Core Based Tree (CBT) network layer multicast
routing protocol. CBT builds a shared multicast distribution tree per
group, and is suited to inter- and intra-domain multicast routing.
CBT is protocol independent in that it makes use of unicast routing to
establish paths between senders and receivers. The CBT architecture is
described in [1].
This document is progressing through the IDMR working group of the IETF.
CBT related documents include [1, 5, 6]. For all IDMR-related documents,
see http://www.cs.ucl.ac.uk/ietf/idmr.
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-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt-spec-07.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-idmr-cbt-spec-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.
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: <19970307104720.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-idmr-cbt-spec-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idmr-cbt-spec-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970307104720.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07403; 10 Mar 97 9:59 EST
Received: from ietf.ietf.org by ietf.org id aa06887; 10 Mar 97 9:52 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-rip at xylogics.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-ripv2-md5-auth-00.txt
Date: Mon, 10 Mar 1997 09:52:54 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703100952.aa06887 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 RIP Version II Working Group
of the IETF.
Title : RIP-II MD5 Authentication
Author(s) : F. Baker
Filename : draft-ietf-ripv2-md5-auth-00.txt
Pages : 14
Date : 03/07/1997
Growth in the Internet has made us aware of the need for improved
authentication of routing information. RIP-II provides for unauthenticated
service (as in classical RIP), or password authentication. Both are
vulnerable to passive attacks currently widespread in the Internet.
Well-understood security issues exist in routing protocols [4]. Clear text
passwords, currently specified for use with RIP-II, are no longer
considered sufficient [5].
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-ripv2-md5-auth-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ripv2-md5-auth-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-ripv2-md5-auth-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: <19970307095329.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ripv2-md5-auth-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ripv2-md5-auth-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970307095329.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07411; 10 Mar 97 9:59 EST
Received: from ietf.ietf.org by ietf.org id aa06989; 10 Mar 97 9:53 EST
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-dvmrp-00.txt
Date: Mon, 10 Mar 1997 09:53:27 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703100953.aa06989 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 Inter-Domain Multicast
Routing Working Group of the IETF.
Title : Core Based Tree (CBT) Multicast Border Router
Specification for Connecting a CBT Stub Region to a
DVMRP Backbone
Author(s) : A. Ballardie
Filename : draft-ietf-idmr-cbt-dvmrp-00.txt
Pages : 9
Date : 03/07/1997
This document specifies the behaviour of CBT multicast border router
interconnecting a CBT multicast stub domain (region) to a DVMRP [1]
multicast backbone.
The document provides guidelines that are intended to be generally aligned
with the mechanisms described in the "Interoperability Rules for Multicast
Routing Protocols" [2]. Certain aspects of those rules may be interpreted
and implemented differently, and therefore some discretion is left to the
implementor.
This document assumes the reader is familiar with the CBT protocol [3].
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-dvmrp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt-dvmrp-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-idmr-cbt-dvmrp-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: <19970307121600.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-idmr-cbt-dvmrp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idmr-cbt-dvmrp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970307121600.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07412; 10 Mar 97 9:59 EST
Received: from ietf.ietf.org by ietf.org id aa06941; 10 Mar 97 9:53 EST
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-arch-04.txt
Date: Mon, 10 Mar 1997 09:53:17 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703100953.aa06941 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 Routing Architecture
Author(s) : A. Ballardie
Filename : draft-ietf-idmr-cbt-arch-04.txt
Pages : 24
Date : 03/07/1997
CBT is a multicast routing architecture that builds a single delivery tree
per group which is shared by all of the group's senders and receivers.
Most multicast algorithms build one multicast tree per sender (subnetwork),
the tree being rooted at the sender's subnetwork. The primary advantage of
the shared tree approach is that it typically offers more favourable
scaling characteristics than all other multicast algorithms.
The CBT protocol [1] is a network layer multicast routing protocol that builds
and maintains a shared delivery tree for a multicast group. The sending
and receiving of multicast data by hosts on a subnetwork conforms to the
traditional IP multicast service model [2].
CBT is progressing through the IDMR working group of the IETF.
The CBT protocol is described in an accompanying document [1].
For this, and all IDMR-related documents, see
http://www.cs.ucl.ac.uk/ietf/idmr
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-arch-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt-arch-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-idmr-cbt-arch-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.
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: <19970307112116.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-idmr-cbt-arch-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idmr-cbt-arch-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970307112116.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07406; 10 Mar 97 9:59 EST
Received: from ietf.ietf.org by ietf.org id aa07051; 10 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-tls at w3.org
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-tls-protocol-01.txt
Date: Mon, 10 Mar 1997 09:53:41 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703100953.aa07051 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 Transport Layer Security
Working Group of the IETF.
Title : The TLS Protocol Version 1.0
Author(s) : T. Dierks, C. Allen
Filename : draft-ietf-tls-protocol-01.txt
Pages : 67
Date : 03/07/1997
This document specifies Version 1.0 of the Transport Layer Security (TLS)
protocol, which is at this stage is strictly based on the Secure Sockets
Layer (SSL) version 3.0 protocol, and is to serve as a basis for future
discussions. The TLS protocol provides communications privacy over the
Internet. The protocol allows client/server applications to communicate in
a way that is designed to prevent eavesdropping, tampering, or message
forgery.
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-tls-protocol-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-tls-protocol-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-tls-protocol-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.
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: <19970307164422.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-tls-protocol-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tls-protocol-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970307164422.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa13662; 10 Mar 97 11:54 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10835;
10 Mar 97 11:54 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <OAA12084 at pad-thai.cam.ov.com>; Mon, 10 Mar 1997 14:49:16 GMT
Date: Mon, 10 Mar 1997 09:46:29 -0500
Message-Id: <9703101446.AA16204 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Rich Salz <rsalz at osf.org>
Cc: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
In-Reply-To: Rich Salz's message of Sat, 8 Mar 1997 01:22:56 -0500 (EST),
<199703080622.BAA28241 at sulphur.osf.org>
Subject: Re: Comments solicited re negotiated mechanism action
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Sat, 8 Mar 1997 01:22:56 -0500 (EST)
From: Rich Salz <rsalz at osf.org>
Why isn't thread-local-storage/thread-specific-data acceptable?
Yes, it would probably bind a particular GSSAPI implementation to
a particular threads package, but I don't see that as onerous:
How many OS's, where you wouldn't have GSSAPI source available to
port, support more than one threads library?
Quite a few, actually. Between non-OS specific thread implementations
like Chris Provenzano's pthreads, and DCE threads (implementing
different versions of the POSIX standard and POSIX draft standards), and
OS-specific thread packages such as are distributed with Solaris and
other vendor operating systems, I consider thread portability to be a
real nightmare.
As for "Redmond" are you talking about the problems with Windows
DLL's and static data, or something else? (There's really no need
to be oblique, is there?)
Yes, that's what I'm referring to; I would have thought that was
obvious. :-)
- Ted
Received: from ietf.org by ietf.org id aa18175; 10 Mar 97 15:00 EST
Received: from suntan.tandem.com by ietf.org id aa17988; 10 Mar 97 14:53 EST
Received: from tigger.tower.tandem.com.tower.tandem.com by suntan.tandem.com (8.6.12/suntan5.970212) for <ietf at ietf.org>
id LAA25037; Mon, 10 Mar 1997 11:50:47 -0800
Received: from oltp-keithe (dhcp95-184.loc252.tandem.com) by tigger.tower.tandem.com.tower.tandem.com (4.1/6main.931028)
id AA18814; Mon, 10 Mar 97 11:56:42 PST
Message-Id: <9703101956.AA18814 at tigger.tower.tandem.com.tower.tandem.com>
Sender:ietf-request at ietf.org
From: Keith Evans <keith at loc252.tandem.com>
To: ietf at ietf.org
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: Announcing TIP BOF at Memphis IETF Meeting, April 9
Date: Mon, 10 Mar 1997 11:51:25 -0800
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
> There will be a TIP "birds of a feather" (BOF) session, 1-2pm, Weds April
> 9th, at the Memphis IETF meeting.
>
> Name: Transaction Internet Protocol (TIP) BOF
>
> Area: Applications
>
> Chair: Keith Evans (keith at loc252.tandem.com)
>
> Description:
>
> The standard method for achieving atomic commitment is the two-phase
> commit protocol.
>
> Numerous two-phase commit protocols have been implemented over the
> years. However, none of them has become widely used in the Internet,
> due mainly to their complexity. Most of that complexity comes from
> the fact that the two-phase commit protocol is bundled together with
> a specific program-to-program communication protocol, and that
> protocol lives on top of a very large infrastructure.
>
> TIP proposes a very simple two-phase commit protocol. It
> achieves its simplicity by specifying only how different nodes agree
> on the outcome of a transaction; it allows (even requires) that the
> subject matter on which the nodes are agreeing be communicated via
> other protocols. By doing so, all of the issues related to
> application communication semantics and data representation
> (to name just a few) are avoided.
>
> It is envisioned that this protocol will be used mainly for a
> transaction manager on one Internet node to communicate with a
> transaction manager on another node.
>
> TIP BOF Agenda: 1) socialise the TIP protocol (presentation),
> 2) solicit feedback re the protocol (questions, suggestions for
> enhancement, etc), 3) ascertain support for moving TIP forward as an
> IETF standard.
>
> The current TIP proposal is described in draft-lyon-itp-nodes-00.txt
>
> General information re this meeting can be found at:
>
> http://www.ietf.org/meetings/Memphis.html
>
> Anyone interested in discussing TIP (particularly those considering TIP
> implementations), and wishing to further TIP as an Internet Standard are
> encouraged to attend.
>
> -Keith
Received: from ietf.org by ietf.org id aa18936; 10 Mar 97 15:11 EST
Received: from tomobiki-cho.cac.washington.edu by ietf.org id aa18889;
10 Mar 97 15:10 EST
Received: from Ikkoku-Kan.Panda.COM (clam at UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id MAA03704; Mon, 10 Mar 1997 12:07:52 -0800 (PST)
Received: from localhost (chince at localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id MAA03411; Mon, 10 Mar 1997 12:07:48 -0800 (PST)
Date: Mon, 10 Mar 1997 11:23:02 -0800 (PST)
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: call for a new email infrastructure
To: ietf at ietf.org
Message-ID: <MailManager.858021782.366.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.
It is high time to put together a working group for a new sender-pays email
infrastructure to replace the current recipient-pays SMTP infrastructure. The
current system works only when their is cooperation between all parties to
keep abuse in check. That has failed.
We can no longer wait for the large ISPs to take action. MCI and BBN are, at
best, mixed. PSI has done nothing (and consequently net 38 is blocked at a
lot of sites). UUNET openly states that it is not their responsibility.
SPRINT bounces email sent to their "abuse" address; when you call the SPRINT
NOC and follow their alternate instructions, you get rude or obscene email
from their employees.
The mechanism that I envision involves the concept of a "message center"; a
site signs up with a message center the way it signs up with an ISP. The site
has its mail MXed to the message center, and disables its own SMTP server.
Message centers would have contractual arrangements with other message centers
for the interchange of mail between them.
To some extent, the message center would play the role that the postal
authorities do with postal mail. The current situation in email is that
everybody puts mail in everybody else's mailbox, whereas with postal mail only
the postal authorities can place mail in someone's mailbox.
The difference with the message center model is that message centers would be
competing non-governmental entities, albeit with a contractual requirement to
interchange mail. So, it is closer to the telephone model, although with a
few additional twists.
The message center would also, in the short term, have an SMTP server for
compatibility with the past, but SMTP mail may be subject to filtering and
other mechanisms.
The purpose of the message center is multifold:
1) The message center authenticates mail as coming from the site, using a
secure message interchange protocol (not SMTP).
2) The message center handles details of charging and cost accounting,
including special arrangements (e.g. EDUs might want to waive charges
with other EDUs).
3) The message center provides a single point by which spam can be blocked.
Suspicious SMTP traffic patterns can be detected, and action taken.
4) The message center could also handle premium services, e.g. the email
equivalent of a 900 number.
The only other choice is government regulation. That option is looking better
all the time. One thing that might get the ISPs attention is legislation that
mandates a UCE charge (much like the junk FAX charge) that is levied against
the originating ISP (or failing that, to the next upstream provider). If ISPs
find themselves socked with a $500/recipient liability for each spam incident,
they may become somewhat more selective about who they sign up as customers.
Received: from ietf.org by ietf.org id aa22147; 10 Mar 97 16:56 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa21909; 10 Mar 97 16:47 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id QAA07185; Mon, 10 Mar 1997 16:43:08 -0500 (EST)
Message-Id: <199703102143.QAA07185 at ig.cs.utk.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: Mark Crispin <MRC at panda.com>
cc: ietf at ietf.org, moore at cs.utk.edu
Subject: Re: call for a new email infrastructure
In-reply-to: Your message of "Mon, 10 Mar 1997 11:23:02 PST."
<MailManager.858021782.366.mrc at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 10 Mar 1997 16:43:08 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> It is high time to put together a working group for a new sender-pays email
> infrastructure to replace the current recipient-pays SMTP
> infrastructure.
Sender-pays doesn't solve the problem. Despite the high cost of snail
mail, the S/N ratio of my incoming snail-mail is far worse than that
of incoming my e-mail. Sender-pays didn't sufficiently discourage
junk faxes either.
A nearly-inevitable result of sender-pays, is that it costs *less* to
send bulk mail than it does to send interpersonal mail. This
increases the incidence of spam.
Be careful what you wish for.
Keith
Received: from ietf.org by ietf.org id aa22796; 10 Mar 97 17:14 EST
Received: from tomobiki-cho.cac.washington.edu by ietf.org id aa22713;
10 Mar 97 17:13 EST
Received: from Ikkoku-Kan.Panda.COM (gnof at UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id OAA03828; Mon, 10 Mar 1997 14:10:36 -0800 (PST)
Received: from localhost (gin at localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id OAA03941; Mon, 10 Mar 1997 14:10:31 -0800 (PST)
Date: Mon, 10 Mar 1997 14:03:54 -0800 (PST)
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: call for a new email infrastructure
To: Keith Moore <moore at cs.utk.edu>
cc: ietf at ietf.org, moore at cs.utk.edu
In-Reply-To: <199703102143.QAA07185 at ig.cs.utk.edu>
Message-ID: <MailManager.858031434.366.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, 10 Mar 1997 16:43:08 -0500, Keith Moore wrote:
> A nearly-inevitable result of sender-pays, is that it costs *less* to
> send bulk mail than it does to send interpersonal mail. This
> increases the incidence of spam.
This can be avoided if the recipients set their own fee schedules.
But, more importantly, it's doubtful that the spammers would want their mail
to be stamped with "bulk mail" postage, given that it would then be trivial
for sites to toss out all bulk mail unconditionally.
Received: from ietf.org by ietf.org id aa24050; 10 Mar 97 17:34 EST
Received: from cnri by ietf.org id aa23990; 10 Mar 97 17:33 EST
Received: from monet.caad.ed.ac.uk by CNRI.Reston.VA.US id aa17953;
10 Mar 97 17:33 EST
Received: from [129.215.100.202] (mac-202.caad.ed.ac.uk [129.215.100.202]) by monet.caad.ed.ac.uk (8.6.13/8.6.9) with SMTP id WAA02208; Mon, 10 Mar 1997 22:29:33 GMT
Date: Mon, 10 Mar 1997 22:29:33 GMT
Message-Id: <199703102229.WAA02208 at monet.caad.ed.ac.uk>
X-Sender: richard at monet.caad.ed.ac.uk
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: gxg9562 at tesla.njit.edu, harfmann at headcheese.daa.uc.edu,
Hartmut.Benz at informatik.uni-stuttgart.de, herzner at zdfzs.arcs.ac.at,
hipparch at sophia.inria.fr, hjoseph at crcg.edu,
hoffmann at osiris.iemar.tuwien.ac.at, holiday at mevis.uni-bremen.de,
hori at ai.rcast.u-tokyo.ac.jp, ianb at ariel.ucs.unimelb.edu.au,
IETF at CNRI.Reston.VA.US, isadsoc at fokus.gmd.de, ivo at modern.u-net.com,
J.A.Self at cbl.leeds.ac.uk, j.jo at eas.gu.edu.au, j.l.alty at lboro.ac.uk,
J.L.Leach at maths.bath.ac.uk, J.McDonnell at cs.ucl.ac.uk, J.Plume at unsw.edu.au,
jakima at cksr.ac.bialystok.pl, james at arch.su.edu.au,
janssent at smtplink.dis.anl.gov, JLA ARMAS <JLAA at arucas.cda.ulpgc.es>,
MALTRET <jlm at gamsau.archi.fr>, jnd at hitl.washington.edu,
joe at gcr2.fcit.monash.edu.au, John.Riley at rd.bbc.co.uk, john17 at mdx.ac.uk,
john at caad.ed.ac.uk, jos.de.bruin at pi.net
Sender:ietf-request at ietf.org
From: Richard Coyne <Richard.Coyne at ed.ac.uk>
Subject: EuropIA'97 registration
Cc: Ronnie.Galloway at ed.ac.uk, mike at caad.ed.ac.uk
Source-Info: From (or Sender) name not authenticated.
If you are intending to register for EuropIA'97, and have not done so, then
please do so urgently, and email your intention to Ronnie.Galloway at ed.ac.uk
Authors 175 pounds stirling
Non-authors 250 pounds stirling
Conference Dinner 27 pounds stirling
EuropIA'97 Design and the Net 2-3 April 1997
Registrations: Ronnie.Galloway at ed.ac.uk
http://www.caad.ed.ac.uk/europia
UnivEd Technologies Limited
11 South College Street, Edinburgh, EH8 9AA
Ph +44 131 650 9020 Fax +44 131 650 9019
---------------------------------------------------------------------------
Richard Coyne Tel: +44 131 650 2332
Department of Architecture Fax: +44 131 650 8019
University of Edinburgh email: Richard.Coyne at ed.ac.uk
20 Chambers Street EH1 1JZ Scotland http://www.caad.ed.ac.uk/~richard/
Received: from ietf.org by ietf.org id aa24834; 10 Mar 97 17:46 EST
Received: from songbird.com by ietf.org id aa24505; 10 Mar 97 17:43 EST
Received: (from kent at localhost) by songbird.com (8.8.3/8.7.3) id OAA05398; Mon, 10 Mar 1997 14:38:17 -0800
Sender:ietf-request at ietf.org
From: Kent Crispin <kent at songbird.com>
Message-Id: <199703102238.OAA05398 at songbird.com>
Subject: Re: call for a new email infrastructure
To: Keith Moore <moore at cs.utk.edu>
Date: Mon, 10 Mar 1997 14:38:17 -0800 (PST)
Cc: MRC at panda.com, ietf at ietf.org, moore at cs.utk.edu
In-Reply-To: <199703102143.QAA07185 at ig.cs.utk.edu> from "Keith Moore" at Mar 10, 97 04:43:08 pm
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Keith Moore allegedly said:
>
> > It is high time to put together a working group for a new sender-pays email
> > infrastructure to replace the current recipient-pays SMTP
> > infrastructure.
>
> Sender-pays doesn't solve the problem. Despite the high cost of snail
> mail, the S/N ratio of my incoming snail-mail is far worse than that
> of incoming my e-mail. Sender-pays didn't sufficiently discourage
> junk faxes either.
>
> A nearly-inevitable result of sender-pays, is that it costs *less* to
> send bulk mail than it does to send interpersonal mail. This
> increases the incidence of spam.
It will always be cheaper to send bulk mail, regardless of who pays.
Another model that might be considered, besides "sender pays", is
"receiver pays for a filtered source" model. That is, if you want
cheap email connectivity, you deal with ads, just like broadcast TV.
Otherwise, you get connectivity that is filtered, like cable TV. You
pay extra for the service, but you avoid most of the spam.
Such a scheme has several advantages, the most important of which is
that it can be implemented on top of the existing infrastructure.
--
Kent Crispin "No reason to get excited",
kent at songbird.com,kc at llnl.gov the thief he kindly spoke...
PGP fingerprint: 5A 16 DA 04 31 33 40 1E 87 DA 29 02 97 A3 46 2F
Received: from ietf.org by ietf.org id aa25766; 10 Mar 97 18:04 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa25694; 10 Mar 97 18:02 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id RAA04616; Mon, 10 Mar 1997 17:57:44 -0500 (EST)
Message-Id: <199703102257.RAA04616 at ig.cs.utk.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: Kent Crispin <kent at songbird.com>
cc: Keith Moore <moore at cs.utk.edu>, MRC at panda.com, ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-reply-to: Your message of "Mon, 10 Mar 1997 14:38:17 PST."
<199703102238.OAA05398 at songbird.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 10 Mar 1997 17:57:44 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> It will always be cheaper to send bulk mail, regardless of who pays.
Right. "Sender-pays" merely increases the difference in cost.
It's difficult to increase the signal-to-noise ratio of a channel by
decreasing the signal level.
Keith
Received: from ietf.org by ietf.org id aa26553; 10 Mar 97 18:18 EST
Received: from apollo.it.hq.nasa.gov by ietf.org id aa26492; 10 Mar 97 18:16 EST
Received: from wirehead.it.hq.nasa.gov (WireHead.it.hq.nasa.gov [131.182.119.88]) by apollo.it.hq.nasa.gov (8.8.3/8.8.3) with ESMTP id SAA25886; Mon, 10 Mar 1997 18:11:49 -0500 (EST)
Received: from localhost (cshenton at localhost) by wirehead.it.hq.nasa.gov (8.6.12/8.6.12) with ESMTP id XAA21603; Mon, 10 Mar 1997 23:14:06 GMT
Message-Id: <199703102314.XAA21603 at wirehead.it.hq.nasa.gov>
X-Authentication-Warning: wirehead.it.hq.nasa.gov: cshenton owned process doing -bs
To: kent at songbird.com
Cc: moore at cs.utk.edu, MRC at panda.com, ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-Reply-To: Your message of "Mon, 10 Mar 1997 14:38:17 -0800 (PST)"
References: <199703102238.OAA05398 at songbird.com>
X-Mailer: Mew version 1.03 on Emacs 19.31.8
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Mon, 10 Mar 1997 18:14:04 -0500
Sender:ietf-request at ietf.org
From: Chris Shenton <cshenton at it.hq.nasa.gov>
Source-Info: From (or Sender) name not authenticated.
On Mon, 10 Mar 1997 14:38:17 -0800 (PST)
Kent Crispin <kent at songbird.com> wrote:
kent> Another model that might be considered, besides "sender pays", is
kent> "receiver pays for a filtered source" model. That is, if you want
kent> cheap email connectivity, you deal with ads, just like broadcast TV.
kent> Otherwise, you get connectivity that is filtered, like cable TV. You
kent> pay extra for the service, but you avoid most of the spam.
Except that the promise of commercial-free (or significantly reduced
commercials) on cable is a dismal failure. They're just different
commercials, placed differently thoughout the hour.
But since the net is demand-driven, it's conceivable for multiple
providers to offer varying degrees of filtering. A serious spam-nazi
filter might, however, significantly slow your mail delivery...
Received: from ietf.org by ietf.org id aa27818; 10 Mar 97 18:44 EST
Received: from callandor.cybercash.com by ietf.org id aa27778;
10 Mar 97 18:43 EST
Received: by callandor.cybercash.com; id SAA04033; Mon, 10 Mar 1997 18:34:34 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma004024; Mon, 10 Mar 97 18:34:07 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA02406; Mon, 10 Mar 97 18:37:07 EST
Date: Mon, 10 Mar 1997 18:37:07 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-Reply-To: <199703102143.QAA07185 at ig.cs.utk.edu>
Message-Id: <Pine.SUN.3.91.970310171505.28778G-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, 10 Mar 1997, Keith Moore wrote:
> Date: Mon, 10 Mar 1997 16:43:08 -0500
> From: Keith Moore <moore at cs.utk.edu>
> To: Mark Crispin <MRC at panda.com>
> Cc: ietf at ietf.org, moore at cs.utk.edu
> Subject: Re: call for a new email infrastructure
>
> > It is high time to put together a working group for a new sender-pays email
> > infrastructure to replace the current recipient-pays SMTP
> > infrastructure.
>
> Sender-pays doesn't solve the problem. Despite the high cost of snail
> mail, the S/N ratio of my incoming snail-mail is far worse than that
> of incoming my e-mail. Sender-pays didn't sufficiently discourage
> junk faxes either.
I don't believe any single mechanism will solve the spam problem or that any
reasonable combination of mechanisms will completely eliminate it. I do
believe that a combination of mechanisms will bring it under reasonable
control. I don't think it is that applicable to compare your spam to real
mail ratio for physical and email today becasue I believe this ratio is
realtively stable for physical mail, which typically costs the sender around
$1 when you get done with postage, printing, buying a reasonable quality
mailing list, etc. In contract, the amount of spam being sent is increasing
exponentially. Commercial rates for bulk email transmission are 0.01 cents
($10 per 100K messages) per address and that includes profit. That's *four*
*orders* *of* *magnitude* cheaper than postal bulk mail.
Ever media (postal, fax, voice, email, ...) is different in terms of cost to
send, cost to receive, intrusiveness, etc., and each will probably require a
different balance of techncial, financial, legal, and social, measures.
> A nearly-inevitable result of sender-pays, is that it costs *less* to
> send bulk mail than it does to send interpersonal mail. This
> increases the incidence of spam.
Not for any sort of sender-pays that I have proposed. You seem to be
making the assumption that the sender pays some sort of actual network
costs in all cases. What you want is to require the sender to pay
whatever the receiver asks, if they want their mail to get through, with
the receiver being easily able to exempt known correspondents and mailing
lists and the like.
> Be careful what you wish for.
I don't claim they are final polished proposals, but what I wish for is full
implementation and deployment of ubiquitious email security and optional
charging capabilities along the lines of
<ftp://ftp.isi.edu//internet-drafts/draft-eastlake-muse-01.txt> and
<ftp://ftp.isi.edu//internet-drafts/draft-eastlake-internet-payment-02.txt>.
> Keith
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 aa28189; 10 Mar 97 18:50 EST
Received: from rodan.UU.NET by ietf.org id aa27981; 10 Mar 97 18:49 EST
Received: from sayshell.UU.NET by rodan.UU.NET with SMTP
(peer crosschecked as: sayshell.UU.NET [153.39.251.30])
id QQcgig29549; Mon, 10 Mar 1997 18:44:48 -0500 (EST)
Message-Id: <QQcgig29549.199703102344 at rodan.UU.NET>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Keith Moore <moore at cs.utk.edu>
cc: Kent Crispin <kent at songbird.com>, MRC at panda.com, ietf at ietf.org
Sender:ietf-request at ietf.org
From: "Louis A. Mamakos" <louie at uu.net>
Subject: Re: call for a new email infrastructure
References: <199703102257.RAA04616 at ig.cs.utk.edu>
In-reply-to: Your message of "Mon, 10 Mar 1997 17:57:44 EST."
<199703102257.RAA04616 at ig.cs.utk.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 10 Mar 1997 18:44:48 -0500
X-Orig-Sender: louie at uu.net
Source-Info: From (or Sender) name not authenticated.
The alternative approach is to push for the deployment of authenticated
(and perhaps privacy enhanced mail). Then user agents could be configured
to apply policy to messages as they receive them. If mailing lists could
be so configured to change forwareding policy based on originator, then
we could make significant progress in seeing the messages we want to
see, and deferring/ignoring/whatever the others.
Louis Mamakos
Received: from ietf.org by ietf.org id aa29576; 10 Mar 97 18:59 EST
Received: from [204.94.142.153] by ietf.org id aa29515; 10 Mar 97 18:58 EST
Received: (from egoshin at localhost) by egoshin.genesyslab.com (8.8.5/8.6.9) id PAA04374 for ietf at ietf.org; Mon, 10 Mar 1997 15:56:50 -0800
Date: Mon, 10 Mar 1997 15:56:50 -0800
Sender:ietf-request at ietf.org
From: Leonid Yegoshin <egoshin at genesyslab.com>
Message-Id: <199703102356.PAA04374 at egoshin.genesyslab.com>
To: ietf at ietf.org
Subject: Re: call for a new email infrastructure
Source-Info: From (or Sender) name not authenticated.
I can suggest yet another way - something like Authentificated Mail
Transfer Protocol. It can take measures to deliver only E-mail which
had authentificated source host (without uncontrolled gating).
After that it can be simple to support the list of hosts with mail
spammers... or list of networks in case of dialup entry points.
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa00667; 10 Mar 97 19:10 EST
Received: from gate2.sprintlink.net by ietf.org id aa00465; 10 Mar 97 19:09 EST
Received: from iscserv.res.sprintlink.net by gate2.sprintlink.net
via smtpd (for ietf.org [132.151.1.19]) with SMTP; 10 Mar 1997 23:56:45 UT
Received: from localhost (ramanan at localhost)
by iscserv.res.sprintlink.net (8.8.5/8.8.5) with SMTP id TAA27960
for <ietf at ietf.org>; Mon, 10 Mar 1997 19:04:18 -0500 (EST)
Date: Mon, 10 Mar 1997 19:04:18 -0500 (EST)
Sender:ietf-request at ietf.org
From: Ramanan <ramanan at sprint.net>
X-Sender: ramanan at iscserv
Reply-To: Ramanan <ramanan at sprint.net>
To: ietf at ietf.org
Subject: Re: call for a new email infrastructure
Message-ID: <Pine.GSO.3.95.970310185655.27751A-100000 at iscserv>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
kent> Another model that might be considered, besides "sender pays", is
kent> "receiver pays for a filtered source" model. That is, if you want
kent> cheap email connectivity, you deal with ads, just like broadcast TV.
kent> Otherwise, you get connectivity that is filtered, like cable TV.You
kent> pay extra for the service, but you avoid most of the spam.
Thats a good suggestion. But has anyone thought of this model --
"sender pays, and receiver gets a percentage or all the
benefit, after all the bulk email is going to be based
on the personal information that receiver provided at some
point"
This way it will be an added incentive for the user (receiver)
and may probably encourage more internet usage. Just a thought !!
--Ramanan
Received: from cnri by ietf.org id aa02896; 10 Mar 97 19:42 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20104;
10 Mar 97 19:42 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <XAA03216 at pad-thai.cam.ov.com>; Mon, 10 Mar 1997 23:16:34 GMT
Message-Id: <332495EB.7535 at dascom.com>
Date: Mon, 10 Mar 1997 15:14:51 -0800
From: John Nunneley <johnn at dascom.com>
Reply-To: johnn at dascom.com
Organization: Dascom
X-Mailer: Mozilla 3.0Gold (Win95; I)
Mime-Version: 1.0
To: cat-ietf at mit.edu
Subject: GSSAPI and SSL?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Is anyone looking into (or have done) integration of SSL under the
GSSAPI?
Is there any interest in the GSSAPI community in this?
Or do you view these things as virtually interchangeable (i.e. solves
the same problem)?
Does this even make any sense?
Thanks, John
--
------------------------------------------------------------------------
John Nunneley Phone: +1 408 457 4510
DASCOM Inc. Fax: +1 408 457 0710
1509 Seabright Avenue Email: johnn at dascom.com
Santa Cruz CA 95062 WWW: http://www.dascom.com/
------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa04087; 10 Mar 97 20:31 EST
Received: from npcc.net by ietf.org id aa03996; 10 Mar 97 20:27 EST
Received: from cjmeyer (dial26.npcc.net [206.160.236.26]) by npcc.net (8.8.3/8.7.3) with ESMTP id UAA13633 for <ietf at ietf.org>; Mon, 10 Mar 1997 20:25:02 -0500 (EST)
Message-Id: <199703110125.UAA13633 at npcc.net>
Sender:ietf-request at ietf.org
From: Carl Meyer <cjmeyer at npcc.net>
To: ietf at ietf.org
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: Re: call for a new email infrastructure
Date: Mon, 10 Mar 1997 20:23:44 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
> I can suggest yet another way - something like Authentificated Mail
> Transfer Protocol. It can take measures to deliver only E-mail which
> had authentificated source host (without uncontrolled gating).
> After that it can be simple to support the list of hosts with mail
> spammers... or list of networks in case of dialup entry points.
I agree. Most half-decent mail readers can filter incoming mail, so all
that is really required is sender authentification. The additional
advantage is that it doesn't even involve the slightest hint of censorship.
Everyone can decide for themselves exactly who they'd like to see mail
from and who they wouldn't. In the most extreme case, a user could simply
block all mail by default, and only allow mail in from chosen users. A
firewall for email, essentially. All that's lacking in the current system
is sender authentification, which I consider a feature worth implementing
in any case, apart from the issue of spam.
peace
(ar|
Received: from ietf.org by ietf.org id aa04157; 10 Mar 97 20:33 EST
Received: from smtp.dtinet.or.jp by ietf.org id aa04114; 10 Mar 97 20:32 EST
Received: from ppp0.shimizu.dtinet.or.jp (ppp0.shimizu.dtinet.or.jp [203.181.70.33]) by smtp.dtinet.or.jp (8.8.4+2.7Wbeta4/3.5Wpl2) with SMTP id KAA19946 for <ietf at ietf.org>; Tue, 11 Mar 1997 10:29:33 +0900 (JST)
Message-Id: <3.0.1.32.19970311100125.006ac06c at twics.com>
X-Sender: martyn at twics.com
X-Mailer: Windows Eudora Pro Version 3.0.1 beta 8 (32)
Date: Tue, 11 Mar 1997 10:01:25 +0900
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Martyn Williams <martyn at twics.com>
Subject: Re: call for a new email infrastructure
In-Reply-To: <199703102238.OAA05398 at songbird.com>
References: <199703102143.QAA07185 at ig.cs.utk.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
> It is high time to put together a working group for a new sender-pays email
> infrastructure to replace the current recipient-pays SMTP
> infrastructure.
If a sender pays system begins it legitimises the use of e-mail for mass
mailing purposes so this path would have to be very carefully taken. I'm
sure once such a system began, it would attract companies that had, until
now, kept from mass mailing because of the resent it causes.
I don't think the idea of the recipient setting the fees would do much
either. Heavy users, who are presumably those most bothered and most vocal
about mass e-mail, would not want to impose a large incoming fee because of
the heavy use they make of the Internet. Thus mass emailers also wouldn't
be detered. It would also have to be very sophisticated because I might
want to impose a $1 a message charge on spammers but would want mailing
lists and email-delivered services to come in for free.
Martyn
--
Martyn Williams |Internet : martyn at twics.com
Shimizu, Japan |Internet : martyn at newsbytes.com
|CompuServe : 74777,1301
http://www.twics.com/~martyn |Fax : 0543-64-0199
Received: from cnri by ietf.org id aa08832; 10 Mar 97 22:47 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22577;
10 Mar 97 22:46 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <CAA09668 at pad-thai.cam.ov.com>; Tue, 11 Mar 1997 02:15:58 GMT
Message-Id: <3.0.32.19970310181259.0070d9c0 at pop-srvr>
X-Sender: arim at pop-srvr
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 10 Mar 1997 18:12:59 -0800
To: johnn at dascom.com, cat-ietf at mit.edu
From: Ari Medvinsky <ari.medvinsky at cybersafe.com>
Subject: Re: GSSAPI and SSL?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
At 03:14 PM 3/10/97 -0800, John Nunneley wrote:
>Is anyone looking into (or have done) integration of SSL under the
>GSSAPI?
>Is there any interest in the GSSAPI community in this?
>Or do you view these things as virtually interchangeable (i.e. solves
>the same problem)?
>Does this even make any sense?
>Thanks, John
I have not looked into this. However, there is an internet draft that
we authored for integrating Kerberos and SSL.
The draft is available from the TLS working group's web page.
cheers,
-Ari
Received: from cnri by ietf.org id aa15368; 11 Mar 97 0:45 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa01592;
11 Mar 97 0:45 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <DAA12794 at pad-thai.cam.ov.com>; Tue, 11 Mar 1997 03:49:10 GMT
Date: Mon, 10 Mar 1997 19:48:14 -0800 (PST)
From: Mike Eisler <Michael.Eisler at eng.sun.com>
Reply-To: Mike Eisler <Michael.Eisler at eng.sun.com>
Subject: Re: GSSAPI and SSL?
To: johnn at dascom.com
Cc: cat-ietf at mit.edu
In-Reply-To: "Your message with ID" <332495EB.7535 at dascom.com>
Message-Id: <Roam 0.9.4.858052094.26887.mre at jurassic.eng.sun.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Precedence: bulk
> Is anyone looking into (or have done) integration of SSL under the
> GSSAPI?
> Is there any interest in the GSSAPI community in this?
> Or do you view these things as virtually interchangeable (i.e. solves
> the same problem)?
> Does this even make any sense?
I've had similar thoughts. One could create a GSS-API mechanism that mimiced
SSL's CipherSuites as QOP values (using the same numerical values). And one
could also mimic SSL's CipherSuite negotiation during the
GSS_Init_sec_context/GSS_Accept_sec_context handshake.
The value in this would be in simplifying the deployment of protocols that use
GSS-API security into operating environments that favor SSL (for example web
browsers). While the result would NOT be the SSL protocol, it would be
security equivalent to what SSL delivers. Presumably, if the operating
environment has modularized the SSL layer appropriately, the GSS-SSL
mechanism could share code with the SSL protocol's API:
internal SSL-api GSS-API
| |
ssl-protocol engine gss-ssl-mech
\ /
ssl-crypto-code
-
Mike Eisler
SunSoft, Inc.
mre at Eng.Sun.Com
Received: from ietf.org by ietf.org id aa15996; 11 Mar 97 1:26 EST
Received: from mail2.microsoft.com by ietf.org id aa15860; 11 Mar 97 1:22 EST
Received: by mail2.microsoft.com with Internet Mail Service (5.0.1457.3)
id <GWWK0J36>; Mon, 10 Mar 1997 21:43:57 -0800
Message-ID: <2120C028D567CF11BB8700805FD4CC4C01E6B2EE at RED-11-MSG.dns.microsoft.com>
Sender:ietf-request at ietf.org
From: Tony Hain <tonyhain at microsoft.com>
To: Martyn Williams <martyn at twics.com>, ietf at ietf.org
Subject: RE: call for a new email infrastructure
Date: Mon, 10 Mar 1997 18:51:17 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Source-Info: From (or Sender) name not authenticated.
Another 'feature' of sender pays would be legal action if arbitrary
blocking (like that done now) is installed. Since the sender has paid
for the right it would be more difficult to argue the bits should be
blocked or hampered in any way before hitting the destination mail box.
This sounds like a box that should be left closed.
Tony
-----Original Message-----
From: Martyn Williams [SMTP:martyn at twics.com]
Sent: Monday, March 10, 1997 5:01 PM
To: ietf at ietf.org
Subject: Re: call for a new email infrastructure
> It is high time to put together a working group for a
new sender-pays email
> infrastructure to replace the current recipient-pays
SMTP
> infrastructure.
If a sender pays system begins it legitimises the use of
e-mail for mass
mailing purposes so this path would have to be very
carefully taken. I'm
sure once such a system began, it would attract
companies that had, until
now, kept from mass mailing because of the resent it
causes.
I don't think the idea of the recipient setting the fees
would do much
either. Heavy users, who are presumably those most
bothered and most vocal
about mass e-mail, would not want to impose a large
incoming fee because of
the heavy use they make of the Internet. Thus mass
emailers also wouldn't
be detered. It would also have to be very sophisticated
because I might
want to impose a $1 a message charge on spammers but
would want mailing
lists and email-delivered services to come in for free.
Martyn
--
Martyn Williams |Internet :
martyn at twics.com
Shimizu, Japan |Internet :
martyn at newsbytes.com
|CompuServe :
74777,1301
http://www.twics.com/~martyn |Fax :
0543-64-0199
Received: from ietf.org by ietf.org id aa15997; 11 Mar 97 1:26 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa15928; 11 Mar 97 1:25 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id BAA08638; Tue, 11 Mar 1997 01:20:54 -0500 (EST)
Message-Id: <199703110620.BAA08638 at ig.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
cc: ietf at ietf.org, moore at cs.utk.edu
Subject: Re: call for a new email infrastructure
In-reply-to: Your message of "Mon, 10 Mar 1997 18:37:07 EST."
<Pine.SUN.3.91.970310171505.28778G-100000 at cybercash.com>
Date: Tue, 11 Mar 1997 01:20:53 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> What you want is to require the sender to pay
> whatever the receiver asks, if they want their mail to get through, with
> the receiver being easily able to exempt known correspondents and mailing
> lists and the like.
Nope, that's nowhere close to what I want. I certainly don't want
to manage a list of people who are allowed to communicate with me
for cheap or free, just so I don't see spam. That would not only
exclude far more traffic than I want to exclude, it would also take
up far more of my time, than dealing with spam.
The cure is worse than the disease.
Keith
Received: from ietf.org by ietf.org id aa17111; 11 Mar 97 1:42 EST
Received: from callandor.cybercash.com by ietf.org id aa17058;
11 Mar 97 1:41 EST
Received: by callandor.cybercash.com; id BAA17631; Tue, 11 Mar 1997 01:32:29 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma017610; Tue, 11 Mar 97 01:31:47 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA08245; Tue, 11 Mar 97 01:34:47 EST
Date: Tue, 11 Mar 1997 01:34:46 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: Tony Hain <tonyhain at microsoft.com>
Cc: ietf at ietf.org
Subject: RE: call for a new email infrastructure
In-Reply-To: <2120C028D567CF11BB8700805FD4CC4C01E6B2EE at RED-11-MSG.dns.microsoft.com>
Message-Id: <Pine.SUN.3.91.970311013359.7676E-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Any reasonable system would only collect a payment if the mail is
accepted.
Donald
On Mon, 10 Mar 1997, Tony Hain wrote:
> Date: Mon, 10 Mar 1997 18:51:17 -0800
> From: Tony Hain <tonyhain at microsoft.com>
> To: Martyn Williams <martyn at twics.com>, ietf at ietf.org
> Subject: RE: call for a new email infrastructure
>
> Another 'feature' of sender pays would be legal action if arbitrary
> blocking (like that done now) is installed. Since the sender has paid
> for the right it would be more difficult to argue the bits should be
> blocked or hampered in any way before hitting the destination mail box.
> This sounds like a box that should be left closed.
>
> Tony
=====================================================================
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 aa18316; 11 Mar 97 2:03 EST
Received: from callandor.cybercash.com by ietf.org id aa18280;
11 Mar 97 2:02 EST
Received: by callandor.cybercash.com; id BAA18110; Tue, 11 Mar 1997 01:53:33 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma018100; Tue, 11 Mar 97 01:53:02 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA08384; Tue, 11 Mar 97 01:56:02 EST
Date: Tue, 11 Mar 1997 01:56:02 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: Keith Moore <moore at cs.utk.edu>
Cc: ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-Reply-To: <199703110620.BAA08638 at ig.cs.utk.edu>
Message-Id: <Pine.SUN.3.91.970311013555.7676F-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
I thought I made it clear that I believe that multiple techniques are needed.
I thought I made it clear that charging was an option.
There are already a growing number of people that bounce all mail that's not
either from entities on a white list or has a magic password in it. Would
you prefer to pay 1 cent, say, the first time you send individual email to
someone (would might then be able to just click on something on their screen
to make future mail from you free) or would you prefer for your mail to
bounce with a message telling you (in some complex way to make it
deliberately hard to process automatically by a spam daemon) to resend with
such a magic password?
On Tue, 11 Mar 1997, Keith Moore wrote:
> Date: Tue, 11 Mar 1997 01:20:53 -0500
> From: Keith Moore <moore at cs.utk.edu>
>
> Nope, that's nowhere close to what I want. I certainly don't want
> to manage a list of people who are allowed to communicate with me
> for cheap or free, just so I don't see spam. That would not only
> exclude far more traffic than I want to exclude, it would also take
> up far more of my time, than dealing with spam.
You are making a lot of unwarranted assumptions about there being a poor
user interface. You should also note that many spammers leave out .edu,
.gov, and some other TLDs. So you are behind the poor people in .com for
general spam volume.
> The cure is worse than the disease.
This particular cure, which I only think shoyld be one of many tools in
the user's arsenal, remains about equally bad or might even get better with
improved user interfaces. Without some action, the disease gets
*exponentially* worse. I remember when I saw spam montly, then weekly, now
daily. How long will it be before its equal to all you regualr mail, then
ten times as much, then a hundred times as much, ...?
> Keith
Security and email syntax checking (including repliability) and IP blocking
and extensive contagiously spread black lists and social pressure and law
suits against spammers and laws against spam, etc., will all help but I think
the ability to impose applications level charges is a tool not to be
dismissed so lightly. And there are other applicaitons such as for pay
services invoked via email.
I didn't write draft-eastlake-internet-payment-02.txt because of spam. I
wrote it to provide a reasonable syntax for payment in the WWW context.
After handling the much more complex cases of the web, it occured to me that
it would be easy to add to a variety of other protocol including SMTP. I was
thinking of this in terms of payment for digital products or services. It
was only later that its possible use against spam occured to me.
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 aa19442; 11 Mar 97 2:48 EST
Received: from deliverator.io.com by ietf.org id aa19364; 11 Mar 97 2:45 EST
Received: from tristero.io.com (tristero.io.com [199.170.88.11])
by deliverator.io.com (8.8.5/8.8.5) with ESMTP id BAA16572
for <ietf at ietf.org>; Tue, 11 Mar 1997 01:28:08 -0600 (CST)
Received: from loopback (dialup-01-191.austin.io.com [199.170.89.191]) by tristero.io.com (8.8.5/8.6.12) with SMTP id BAA10054 for <ietf at ietf.org>; Tue, 11 Mar 1997 01:28:07 -0600 (CST)
Date: Tue, 11 Mar 1997 01:28:49 -0600 (CST)
Sender:ietf-request at ietf.org
From: John Harvey <johnbob at io.com>
X-Sender: johnbob at loopback
To: ietf at ietf.org
Subject: Re: call for a new email infrastructure
Message-ID: <Pine.A32.3.95.970311010201.18204A-100000 at loopback>
X-No-Archive: Yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Perhaps we could develop a fetch based email system. Instead of sending
out the body of the message itself send a message id and a location from
which to fetch it. The sender would automatically be identified to some
extent because the fetch information would have to be valid for it to
work. The sender couldn't hit-and-run with a throwaway account because
the account would have to be valid long enough for the receiver to fetch
the body. Any receiver could reject mail by simply not fetching it. The
sender would have to store the messages on their disk or whatever storage
for however long they think the receivers will wait to fetch them. (This
probably wouldn't be a burden to junkmailers that are sending the same
message to everyone though.) For mailing lists (that you subscribe to,
like ietf) the message id and location could be forwarded instead of the
body so that it can be fetched from the originator.
hurm,
-john
John Harvey Email advertisers: put me on your "don't call, don't email" list.
home: johnbob at io. com http://www .io. com/~johnbob/
Received: from ietf.org by ietf.org id aa20917; 11 Mar 97 3:46 EST
Received: from SYNW06.elettra.trieste.it by ietf.org id aa20864;
11 Mar 97 3:45 EST
Date: Tue, 11 Mar 1997 9:41:14 +0100
To: ietf at ietf.org
CC: ALLOCCHIO at elettra.trieste.it
Message-Id: <970311094114.600534 at elettra.trieste.it>
Sender:ietf-request at ietf.org
From: "Claudio Allocchio, +39 40 3758523" <Claudio.Allocchio at elettra.trieste.it>
Subject: re: call for a new email infrastructure
Source-Info: From (or Sender) name not authenticated.
Unsolicited mail is an old and more expanding problem... we called already for
suggestions, BOFs...
Sender-pays does not solve the problem at all:
- if sender pays, he feels legitimate to send as much unsolicited e-mail he/she
can afford to send. It means we will have "wealthy" entities flooding us,
and little ones sending only little stuff.
- if sender pays and we block his/her messages, he/she could take legal actions
against recepients, or anybody blocking his/her traffic... too bad!
We need a mixture of actions to limit the e-mail abuse:
- encourage the installation of "trusted mailers", i.e. objects which ONLY
accept and forward authenticated mail message. This also solves other
problems like fake messaging.
- adopt "level 3" filtering policy against proved sources of unsolicited
messages: after repeated abuse from a source, that network is filtered out
by major routers in the "area". If the area is the world and the routers
are the critical ones, the damage to the abuser can really affect his/her
complete business. As an example, the italian ISP are thinking to adopt
such a policy, filtering out abusers on the international and ISP to ISP
routers; level 3 filtering can be a total block, but they already all agreed
to have customers sign up contracts where they accept explicitly that mail
spamming is a violation of in force rules, thus they CAN act like this, if
they wish.
- add options to local MTAs like
list of rejected addresses/domains
list of accepted addresses/domains
i.e. sender accept/deny access lists
with options as "bounce / spool to dev/null" for rejected messages
(something like "Please do not disturb" hanging on the MTA). It is the same
idea used when you have called ID enabled on your phone and you can somehow
identify undesired callers.
other ideas?
regards
Claudio
Received: from ietf.org by ietf.org id aa23997; 11 Mar 97 7:28 EST
Received: from usr07.primenet.com by ietf.org id aa23898; 11 Mar 97 7:24 EST
Received: from primenet.com (root at mailhost02.primenet.com [206.165.5.53])
by usr07.primenet.com (8.8.5/8.8.5) with ESMTP id FAA02497
for <ietf at ietf.org>; Tue, 11 Mar 1997 05:21:15 -0700 (MST)
Received: from primenet.primenet.com (ip172.boi.primenet.com [198.68.45.172])
by primenet.com (8.8.5/8.8.5) with ESMTP id FAA20361
for <ietf at ietf.org>; Tue, 11 Mar 1997 05:21:12 -0700 (MST)
Message-Id: <199703111221.FAA20361 at primenet.com>
Sender:ietf-request at ietf.org
From: Michael Quinlan <mikeq at primenet.com>
To: ietf at ietf.org
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: Re: call for a new email infrastructure
Date: Tue, 11 Mar 1997 05:23:10 -0700
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
> From: Martyn Williams <martyn at twics.com>
>
> I don't think the idea of the recipient setting the fees would do much
> either. Heavy users, who are presumably those most bothered and most
vocal
> about mass e-mail, would not want to impose a large incoming fee because
of
> the heavy use they make of the Internet. Thus mass emailers also wouldn't
> be detered. It would also have to be very sophisticated because I might
> want to impose a $1 a message charge on spammers but would want mailing
> lists and email-delivered services to come in for free.
More people should learn to play chess. If you charge $1 for spam, but let
mailing lists come in for free, what is the next move for the spammers?
They will send spam via unmoderated mailing lists that you subscribe to
(such as this one).
I vote for authenticated mailing, then I can filter the mail the way I want
to.
Received: from ietf.org by ietf.org id aa25099; 11 Mar 97 8:00 EST
Received: from smtpgw.ed.nce.sita.int by ietf.org id aa25044; 11 Mar 97 7:59 EST
Return-Path: <steen.larsen at smtpgw>
Received: from rdsita.rd-sita.fr by smtpgw.ed.nce.sita.int (8.7.5/SitaNet-1.5)
id NAA07500; Tue, 11 Mar 1997 13:54:23 +0100 (MET)
Received: from slarsen.ed.nce.sita.int (pc-edstl.ed.nce.sita.int) by rdsita.rd-sita.fr (5.0/SMI-SVR4)
id AA01175; Tue, 11 Mar 1997 13:55:31 --100
Message-Id: <3325566B.EA8 at ed.nce.sita.int>
Date: Tue, 11 Mar 1997 13:56:12 +0100
Sender:ietf-request at ietf.org
From: Steen Larsen <steen.larsen at ed.nce.sita.int>
Reply-To: steen.larsen at ed.nce.sita.int
Organization: SITA R&D Nice
X-Mailer: Mozilla 4.0b2 (Win95; I)
Mime-Version: 1.0
To: John Harvey <johnbob at io.com>
Cc: ietf at ietf.org
Subject: Re: call for a new email infrastructure - Not needed
X-Priority: 3 (Normal)
References: <Pine.A32.3.95.970311010201.18204A-100000 at loopback>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
John Harvey wrote:
Perhaps we could develop a fetch based email system. Instead of
sending
out the body of the message itself send a message id and a location
from
which to fetch it. ....
MIME has this already. It is also common to use e-mail with HTML where
the main content
is retrieved by following a URL.
Best regards
Steen Larsen
--
Steen Koefoed Larsen
SITA R&D Nice, France | @ Home
E-mail: steen.larsen at ed.nce.sita.int | NEW E-mail: steen at who.net
Phone : +33 4 92.96.63.67 | GSM Mobile: +45 40512486
Fax : +33 4 92.96.64.92 | or (French) +33 6 09090568
Disclaimer: This letter may reflect my personal opinion.
*** Syntax? Why not - they tax everything else! ***
Received: from ietf.org by ietf.org id aa25210; 11 Mar 97 8:03 EST
Received: from tucows.alphanet.com.br by ietf.org id aa25169; 11 Mar 97 8:03 EST
Received: from tucows.alphanet.com.br (andre at tucows.alphanet.com.br [200.246.167.105]) by tucows.alphanet.com.br (8.7.5/8.7.3) with SMTP id KAA02452; Tue, 11 Mar 1997 10:00:19 -0300
Date: Tue, 11 Mar 1997 10:00:18 -0300 (EST)
Sender:ietf-request at ietf.org
From: Andre Correa <andre at tucows.alphanet.com.br>
Reply-To: Andre Correa <andre at tucows.alphanet.com.br>
To: Keith Moore <moore at cs.utk.edu>
cc: Kent Crispin <kent at songbird.com>, MRC at panda.com, ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-Reply-To: <199703102257.RAA04616 at ig.cs.utk.edu>
Message-ID: <Pine.LNX.3.93.970310204810.891A-100000 at tucows.alphanet.com.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Hello, I have no idea how this mails from IETF came to me, anyway
I have an opinion about it all: (and it is good to be here)
I use and work with Internet for 3 years and I received a little
number of unwanted mails, maybe, I am a luck guy, but I dont want to pay
to send or to receive mails, I want it to stay the way it is. Why dont
create this service of "mesage center" for those who want to have their
mails filtred, this guys will pay for the service of filtering their
e-mail...
Other thing, what we will gonna do with the large mailling lists??
Who will pay to send this mails for tousands of users??
My way looks better for me. Till now the Internet was a free field
and must continue this way!!! We must find and make something realy strong
and definitive with the bombers and guys that send unwanted mails.
Anyway this is just my opinion...
[]s.
<Andre>
Received: from ietf.org by ietf.org id aa26269; 11 Mar 97 8:19 EST
Received: from ns.jck.com by ietf.org id aa26195; 11 Mar 97 8:18 EST
Received: from tp7.Jck.com ("port 1434"@tp7.jck.com)
by a4.jck.com (PMDF V5.1-7 #21705) with SMTP id <0E6VRI0HI005N4 at a4.jck.com>
for ietf at ietf.org; Tue, 11 Mar 1997 08:15:36 -0500 (EST)
Date: Tue, 11 Mar 1997 08:15:35 -0500 (EST)
Sender:ietf-request at ietf.org
From: John C Klensin <klensin at mci.net>
Subject: Re: call for a new email infrastructure
In-reply-to: <199703111221.FAA20361 at primenet.com>
To: ietf at ietf.org
Message-id: <SIMEON.9703110835.Q at tp7.Jck.com>
MIME-version: 1.0
X-Mailer: Simeon for Win32 Version 4.1.1b1 Build (5)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Priority: NORMAL
X-Authentication: none
Source-Info: From (or Sender) name not authenticated.
Looks like this discussion is going to go on forever, with
a S/N ratio just above spam. Let me try to draw a
few threads together, at least from the perspective
of one person who receives a *lot* of email.
* The thing I don't like about spam is that it is
unsolicited, has content I'm not interested in, takes up
bandwidth and time (on days when I pull mail through a
high-speed link, email trash (of any flavor) bothers me
less than when I have to suck it through a dialup-speed
connection, where I can painlessly delete it. I get most
of my smail at a post office box. The people in the post
office used to tease me, as I carried things directly from
the box to the trash barrel, that they had to do a lot of
work to deliver the stuff. I told them that they were paid
to deliver it; I wasn't paid to either read it or to carry
it around.
IMAP provides some help for this problem during the window
between when lots of people start using it and when the
spammers wise up enough to stop sending out messages with
subject lines like "!!!earn quick cash!!!"
* "Charge sender" changes the economic incentives a bit,
but I'm no more interested in receiving unsolicited trash
email from those who can pay than from those who can't/
won't. I think it would make useful social policy in some
ways, but that it isn't much of a solution.
* Selective sender charges, based on review of who is
sending, would either require a trusted mail backbone
(e.g., an official provider similar to national Post
Offices interconnected by treaties or the arrangements
anticipated between X.400 ADMDs) or would effectively
eliminate relays and most gateways from the Internet. Now,
while I consider relays and gateways to be the
sources of many problems, eliminating them would severely
reduce the range and scope of Internet mail.
* I would value the combination of authenticated mail and
server-based filters that would permit incoming mail to be
sorted into (at least) five filters/priorities:
(i) authenticated mail from sources on a white list
(ii) authenticated and verifiable mail from
other sources not falling into category (iv)
(iii) unidentified and unauthenticated mail
(iv) authenticated or unauthenticated mail from sources
on a black list
I might choose to trash the fourth category entirely; it
might take a l-o-n-g time for me to get around to reading
the third. And the ability to make these distinctions
would clearly permit a relay to reject any traffic not from
one of its customers, which would eliminate some of the
current problems without imposing intrastructure changes.
To do better than that, I need server-based content
analysis of incoming messages, content analysis that is
good enough to distinguish trash from discussions of trash
in which I might be interested. That is a seriously hard
problem unless I hire a human being to filter my mail.
What do we need for this?
-- Some agreement on standards for authenticated and
verifiable mail, and wide deployment of things that reflect
those standards. (Very hard, apparently)
-- Standards and tools for management of server-based
filters that can do the work above (and more). (Shouldn't
be rocket science, but we haven't been able to focus IETF
energy on this in the last several years)
-- No basic infrastructure changes
--john
Received: from ietf.org by ietf.org id aa27499; 11 Mar 97 8:35 EST
Received: from box.nl by ietf.org id aa27415; 11 Mar 97 8:33 EST
Received: from cs-gj3-a11.hro.nl (cs-gj3-a11.hro.nl [145.24.129.143]) by box.nl (8.7.5/8.6.9) with SMTP id OAA04876 for <ietf at ietf.org>; Tue, 11 Mar 1997 14:30:26 +0100
Date: Tue, 11 Mar 1997 14:30:26 +0100
Message-Id: <199703111330.OAA04876 at box.nl>
X-Sender: unit at box.nl (Unverified)
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: michael_roetto <mike at box.nl>
Subject: remove
Source-Info: From (or Sender) name not authenticated.
remove
::::::::::::::::::::::::::::::::::::::::::
: Internet Design Unit :
: http://www.box.nl/~unit/idu :
: :
: Personal Page: :
: http://www.box.nl/~unit/mike :
::::::::::::::::::::::::::::::::::::::::::
Received: from ietf.org by ietf.org id aa27521; 11 Mar 97 8:35 EST
Received: from box.nl by ietf.org id aa27466; 11 Mar 97 8:35 EST
Received: from cs-gj3-a11.hro.nl (cs-gj3-a11.hro.nl [145.24.129.143]) by box.nl (8.7.5/8.6.9) with SMTP id OAA04890 for <ietf at ietf.org>; Tue, 11 Mar 1997 14:31:27 +0100
Date: Tue, 11 Mar 1997 14:31:27 +0100
Message-Id: <199703111331.OAA04890 at box.nl>
X-Sender: unit at box.nl (Unverified)
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: michael_roetto <mike at box.nl>
Subject: remove
Source-Info: From (or Sender) name not authenticated.
remove
::::::::::::::::::::::::::::::::::::::::::
: Internet Design Unit :
: http://www.box.nl/~unit/idu :
: :
: Personal Page: :
: http://www.box.nl/~unit/mike :
::::::::::::::::::::::::::::::::::::::::::
Received: from ietf.org by ietf.org id aa27464; 11 Mar 97 8:35 EST
Received: from ietf.ietf.org by ietf.org id aa27362; 11 Mar 97 8:33 EST
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: social at ietf38.fedex.net
Subject: 38th IETF Social
Date: Tue, 11 Mar 1997 08:33:21 -0500
X-Orig-Sender: mbeaulie at ietf.org
Message-ID: <9703110833.aa27362 at ietf.org>
FedEx presents an evening of Da' Blues by Jo Jo and Delwood, the Other
Brothers of "The Other Brothers Blues" band at the Memphis Peabody Hotel
Skyway Ballroom.
They are on a mission from God, to party with the IETF. They are told the
live band, dancing to their favorite music, unlimited Arcade games,
Caricaturists, Cool View, Memphis Food, and Tubs of Beer will be well worth
the drive from Chicago.
DATE:
Tuesday, April 8th, 1997
TIME:
7 p.m.
LOCATION:
Memphis Peabody Hotel Skyway Ballroom
149 Union Avenue
Memphis, TN
The Peabody is located within walking distance or a trolley ride from most
of the downtown hotels.
PAYMENT:
US $30.00 in advance, (cash or check drawn on a U.S. bank only). Advance
payment will be taken at the Social Event table near the IETF Registration
Desk during registration hours.
COCKTAILS AND DINNER:
Hosted beer, wine and soft drinks will be served from 7:00 p.m. - 10:00 p.m.
MENU:
Memphis' World Famous Corky's BBQ
Baked Beans
Slaw
Grilled Vegetable Pita Pockets
Potato Skins with assorted toppings
Hot & Spicy Chicken Wings
Chinese Egg Rolls with Hot Mustard
Sliced Roast Turkey
French/Herb Rolls
Chips & Dips
Brownies
Lots of Good Food!
---------------------------------------------------------------------------
REGISTRATION FORM
RSVP to: social at ietf38.fedex.net SUBJECT: RSVP IETF Social
Memphis IETF Social
Hosted by FedEx
Peabody Hotel Skyway Ballroom
Tuesday, April 8th, 1997
7 p.m.
Cash (U.S. dollars) or company/personal checks (drawn on U.S. banks) are
acceptable. Credit Cards, purchase orders, money orders, bank checks, and
traveler's checks cannot be accepted.
NAME ________________________________________________
ORGANIZAION ________________________________________
NUMBER OF RESERVATIONS REQUESTED ___________________
Note: Registrations confirmed at http://ietf38.fedex.net/social.html
Received: from ietf.org by ietf.org id aa27641; 11 Mar 97 8:38 EST
Received: from smtpgw.ed.nce.sita.int by ietf.org id aa27594; 11 Mar 97 8:38 EST
Return-Path: <steen.larsen at smtpgw>
Received: from rdsita.rd-sita.fr by smtpgw.ed.nce.sita.int (8.7.5/SitaNet-1.5)
id OAA07676; Tue, 11 Mar 1997 14:33:15 +0100 (MET)
Received: from slarsen.ed.nce.sita.int (pc-edstl.ed.nce.sita.int) by rdsita.rd-sita.fr (5.0/SMI-SVR4)
id AA01428; Tue, 11 Mar 1997 14:34:23 --100
Message-Id: <33255F86.4453 at ed.nce.sita.int>
Date: Tue, 11 Mar 1997 14:35:03 +0100
Sender:ietf-request at ietf.org
From: Steen Larsen <steen.larsen at ed.nce.sita.int>
Reply-To: steen.larsen at ed.nce.sita.int
Organization: SITA R&D Nice
X-Mailer: Mozilla 4.0b2 (Win95; I)
Mime-Version: 1.0
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
Cc: ietf at ietf.org
Subject: Re: call for a new email infrastructure - MUSE comments
X-Priority: 3 (Normal)
References: <Pine.SUN.3.91.970310171505.28778G-100000 at cybercash.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
Donald E. Eastlake 3rd wrote:
Not for any sort of sender-pays that I have proposed. You seem to
be
making the assumption that the sender pays some sort of actual
network
costs in all cases. What you want is to require the sender to pay
whatever the receiver asks, if they want their mail to get through,
with
the receiver being easily able to exempt known correspondents and
mailing
lists and the like.
Yes, we don't want to junk good old SMTP just to deal with spam.
The above is a good idea. We will only read mail that arrives with an
embedded payment.
Our friends will get free personal e-cash for that purpose. Spammers
will have to
enclose real hard-currency e-cash.
Mail without sufficient payment could simply be bounced, the bounce
message
could include e-cash with a statement that it can only be used for
personal e-mail
purposes. If somebody violates that contract, we sue.
If I am willing to read junk-mail for a price then the bounce message
also includes
my required price and payment method for reading spam mail.
Note: The "personal e-cash" could be a simple string/password that lets
mail through.
This string could be copyrighted forbidding its use for spamming
purposes.
I don't claim they are final polished proposals, but what I wish for
is full
implementation and deployment of ubiquitious email security and
optional
charging capabilities along the lines of
<ftp://ftp.isi.edu//internet-drafts/draft-eastlake-muse-01.txt> and
<ftp://ftp.isi.edu//internet-drafts/draft-eastlake-internet-payment-02.txt>.
The MUSE document tries to move security/payment functionality from the
user agent to the SMTP servers. I think this is a bad idea. Keeping as
much
functionality in the UA as possible makes it much easier for users to
start using new
features: They don't have to wait for the whole SMTP infrastructure to
be upgraded,
instead they buy a new UA and use it immediately with similar users.
This is why SMTP / RFC 822 has been so successful compared to X.400.
(X.400
tried to put tons of cuntionality into the MTAs)
So please define some RFC 822 headers to contain the payment strings.
Best regards
Steen Larsen
PS. As you said, many different mechanisms may be needed to stop
spam. I do not rule
out that SMTP level payment can be used too. I just think the
other is more important.
--
Steen Koefoed Larsen
SITA R&D Nice, France | @ Home
E-mail: steen.larsen at ed.nce.sita.int | NEW E-mail: steen at who.net
Phone : +33 4 92.96.63.67 | GSM Mobile: +45 40512486
Fax : +33 4 92.96.64.92 | or (French) +33 6 09090568
Disclaimer: This letter may reflect my personal opinion.
*** Syntax? Why not - they tax everything else! ***
Received: from ietf.org by ietf.org id aa27854; 11 Mar 97 8:41 EST
Received: from box.nl by ietf.org id aa27810; 11 Mar 97 8:41 EST
Received: from cs-gj3-a11.hro.nl (cs-gj3-a11.hro.nl [145.24.129.143]) by box.nl (8.7.5/8.6.9) with SMTP id OAA04943 for <ietf at ietf.org>; Tue, 11 Mar 1997 14:38:35 +0100
Date: Tue, 11 Mar 1997 14:38:35 +0100
Message-Id: <199703111338.OAA04943 at box.nl>
X-Sender: unit at box.nl (Unverified)
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: michael_roetto <mike at box.nl>
Subject: remove
Source-Info: From (or Sender) name not authenticated.
remove
::::::::::::::::::::::::::::::::::::::::::
: Internet Design Unit :
: http://www.box.nl/~unit/idu :
: :
: Personal Page: :
: http://www.box.nl/~unit/mike :
::::::::::::::::::::::::::::::::::::::::::
Received: from ietf.org by ietf.org id aa02527; 11 Mar 97 10:11 EST
Received: from achilles.ctd.anl.gov by ietf.org id aa02353; 11 Mar 97 10:07 EST
Received: from Raiken.fred.net (raiken.fred.net [205.161.109.24]) by achilles.ctd.anl.gov (8.6.11/8.6.11) with SMTP id JAA02208; Tue, 11 Mar 1997 09:03:20 -0600
Message-Id: <2.2.32.19970311150626.007574d0 at pop3.ctd.anl.gov>
X-Sender: aiken at pop3.ctd.anl.gov
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 11 Mar 1997 10:06:26 -0500
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
Sender:ietf-request at ietf.org
From: Bob Aiken <raiken at anl.gov>
Subject: RE: call for a new email infrastructure
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 01:34 AM 3/11/97 -0500, you wrote:
>Any reasonable system would only collect a payment if the mail is
>accepted.
Accepted by whom? A lot of people use POP and IMAP servers which
"accept" the email for said person at mailgw.dom.dom and its not until
either a user glances at the headers (IMAP) or sucks down the mail
(POP) before the end user can decide if they WANT a message or not.
Is acceptance at the MTA (POP or IMAP servers) or at the UA (Eudora,
MX, ...)?
I agree with Tony Hain in that the sender paying has some major problems -
Unless of course we have the sender DIRECTLY PAY the receiver, i.e. change
the model of sender A paying ISP P to spam anyone on ISPs X,Y, and Z - to
one where
sender A must pay ISP P as well as the receiver of the spam. Just because
spammer A pays ISP P does not give them the right to send me email when I
have no agreement with either ISP P or the spammer. I would think blocking
at my MTA or host is not illegal (although I qualify this statement with the
fact I am not - nor wish to be a lawyer). The Internet is not the US postal
system (Thank god for that) and we shold endeavor to make sure it does not
become one, therefore the fact that the US postal system allows Spammers to
send loads of unsolicited
garbage everyday to many people (and its illegal for the postoffice to
filter - although they do this randomly by loosing mail from time to time)
should not
restrict us from pursuing better ways (i.e., the sender of spam MUST pay me
to accept their SPAM since I pay my IPS etc.) to solve this issue. This
would do wonders in advancing electronic commerce and
cyberbucks/cybergold/cyberchits. Consider sender A sending a mesg to B
saying I am sending you UNSOLICITED garbage and I will pay you x to accept
it- thus paying receiver B (assuming B accepts it - B could also refuse to
accept it).
bob
>
>Donald
>
>On Mon, 10 Mar 1997, Tony Hain wrote:
>
>> Date: Mon, 10 Mar 1997 18:51:17 -0800
>> From: Tony Hain <tonyhain at microsoft.com>
>> To: Martyn Williams <martyn at twics.com>, ietf at ietf.org
>> Subject: RE: call for a new email infrastructure
>>
>> Another 'feature' of sender pays would be legal action if arbitrary
>> blocking (like that done now) is installed. Since the sender has paid
>> for the right it would be more difficult to argue the bits should be
>> blocked or hampered in any way before hitting the destination mail box.
>> This sounds like a box that should be left closed.
>>
>> Tony
>
>=====================================================================
>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
>
>
>
Robert J. Aiken (Bob), Argonne National Lab,
Network Research Manager, raiken at anl.gov, 301-271-2919
"silence can be a speech"
Received: from ietf.org by ietf.org id aa03174; 11 Mar 97 10:29 EST
Received: from ns1.evcom.net by ietf.org id aa03081; 11 Mar 97 10:27 EST
Received: from eci-1 (eci-1.evcom.net [208.136.203.11]) by ns1.evcom.net (8.8.5/8.6.12) with ESMTP id KAA27569 for <ietf at ietf.org>; Tue, 11 Mar 1997 10:23:56 -0500
Message-Id: <199703111523.KAA27569 at ns1.evcom.net>
Sender:ietf-request at ietf.org
From: Alex <alexa at evcom.net>
To: ietf at ietf.org
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: remove
Date: Tue, 11 Mar 1997 10:21:56 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
remove
Received: from ietf.org by ietf.org id aa04257; 11 Mar 97 10:47 EST
Received: from mailrelay1.csn.net by ietf.org id aa03977; 11 Mar 97 10:43 EST
Received: from [199.117.162.164] (tang.csn.net [199.117.162.164]) by mailrelay.csn.net (8.7.5/8.7.3) with ESMTP id IAA08261; Tue, 11 Mar 1997 08:39:33 -0700
X-Sender: duffy at medusa.csn.net
Message-Id: <l03020904af4b2d2f00d0 at [199.117.162.164]>
In-Reply-To: <2.2.32.19970311150626.007574d0 at pop3.ctd.anl.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 11 Mar 1997 08:44:12 -0700
To: Bob Aiken <raiken at anl.gov>
Sender:ietf-request at ietf.org
From: Rick Duffy <duffy at sni.net>
Subject: RE: call for a new email infrastructure
Cc: "Donald E. Eastlake 3rd" <dee at cybercash.com>, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 10:06 AM -0500 3/11/97, Bob Aiken wrote:
>At 01:34 AM 3/11/97 -0500, you wrote:
>>Any reasonable system would only collect a payment if the mail is
>>accepted.
>
>Accepted by whom? A lot of people use POP and IMAP servers which
>"accept" the email for said person at mailgw.dom.dom and its not until
>either a user glances at the headers (IMAP) or sucks down the mail
>(POP) before the end user can decide if they WANT a message or not.
>Is acceptance at the MTA (POP or IMAP servers) or at the UA (Eudora,
>MX, ...)?
>
>I agree with Tony Hain in that the sender paying has some major problems -
>Unless of course we have the sender DIRECTLY PAY the receiver, i.e. change
>the model of sender A paying ISP P to spam anyone on ISPs X,Y, and Z - to
>one where
>sender A must pay ISP P as well as the receiver of the spam. Just because
>spammer A pays ISP P does not give them the right to send me email when I
>have no agreement with either ISP P or the spammer. I would think blocking
>at my MTA or host is not illegal (although I qualify this statement with the
>fact I am not - nor wish to be a lawyer). The Internet is not the US postal
>system (Thank god for that) and we shold endeavor to make sure it does not
>become one, therefore the fact that the US postal system allows Spammers to
>send loads of unsolicited
>garbage everyday to many people (and its illegal for the postoffice to
>filter - although they do this randomly by loosing mail from time to time)
>should not
>restrict us from pursuing better ways (i.e., the sender of spam MUST pay me
>to accept their SPAM since I pay my IPS etc.) to solve this issue. This
>would do wonders in advancing electronic commerce and
>cyberbucks/cybergold/cyberchits. Consider sender A sending a mesg to B
>saying I am sending you UNSOLICITED garbage and I will pay you x to accept
>it- thus paying receiver B (assuming B accepts it - B could also refuse to
>accept it).
If email of this type had to be clearly identified as such (probably by some
new protocol), wouldn't it be fairly easy to incorporate an automated method
of simply accepting all spam email, and trashing it immediately, and collect
the chits? If so, then this method would not be looked on favorably by the
senders, and so would encourage them to not play along.
... Rick
Received: from ietf.org by ietf.org id aa06079; 11 Mar 97 11:19 EST
Received: from deliverator.io.com by ietf.org id aa05837; 11 Mar 97 11:14 EST
Received: from hollerith.io.com (hollerith.io.com [199.170.88.21])
by deliverator.io.com (8.8.5/8.8.5) with ESMTP id JAA06184;
Tue, 11 Mar 1997 09:15:40 -0600 (CST)
Received: from loopback (dialup-01-127.austin.io.com [199.170.89.127]) by hollerith.io.com (8.8.5/8.6.12) with SMTP id JAA24340; Tue, 11 Mar 1997 09:15:36 -0600 (CST)
Date: Tue, 11 Mar 1997 09:16:18 -0600 (CST)
Sender:ietf-request at ietf.org
From: John Harvey <johnbob at io.com>
X-Sender: johnbob at loopback
To: Steen Larsen <steen.larsen at ed.nce.sita.int>
cc: ietf at ietf.org
Subject: Re: call for a new email infrastructure - Not needed
In-Reply-To: <3325566B.EA8 at ed.nce.sita.int>
Message-ID: <Pine.A32.3.95.970311090035.16818A-100000 at loopback>
X-No-Archive: Yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Tue, 11 Mar 1997, Steen Larsen wrote:
> MIME has this already. It is also common to use e-mail with HTML where
> the main content
> is retrieved by following a URL.
Yes, the mechanism exists with MIME. But there is no policy that all must
use it.
I'm trying to find a way that the basic mail system requires accurate
identification of the source. Some way that a junkmail message body never
leaves the source except to people who want it. Some way that the initial
unsolicited part of the message is a small as possible, contains no
text (not even a subject line) and can be used for filtering.
I understand why people don't want to change or give up SMTP. Would
anyone be opposed to having SMTP and a new system coexist?
-john
John Harvey Email advertisers: put me on your "don't call, don't email" list.
home: johnbob at io. com http://www .io. com/~johnbob/
X-No-Archive: Yes
Received: from ietf.org by ietf.org id aa07365; 11 Mar 97 11:51 EST
Received: from mailhost2.cac.washington.edu by ietf.org id aa06926;
11 Mar 97 11:45 EST
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
by mailhost2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW96.12) with SMTP
id IAA02256; Tue, 11 Mar 1997 08:43:01 -0800
Date: Tue, 11 Mar 1997 08:40:37 -0800 (PST)
Sender:ietf-request at ietf.org
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at tomobiki-cho.cac.washington.edu>
Subject: RE: call for a new email infrastructure
To: Tony Hain <tonyhain at microsoft.com>
cc: Martyn Williams <martyn at twics.com>, ietf at ietf.org
In-Reply-To: <2120C028D567CF11BB8700805FD4CC4C01E6B2EE at RED-11-MSG.dns.microsoft.com>
Message-ID: <MailManager.858098437.5225.mrc at Tomobiki-Cho.CAC.Washington.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 10 Mar 1997 18:51:17 -0800, Tony Hain wrote:
> Another 'feature' of sender pays would be legal action if arbitrary
> blocking (like that done now) is installed. Since the sender has paid
> for the right it would be more difficult to argue the bits should be
> blocked or hampered in any way before hitting the destination mail box.
I will happily accept advertising from any sender who pays me $1 per message.
Received: from ietf.org by ietf.org id aa08749; 11 Mar 97 12:22 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa08227; 11 Mar 97 12:11 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id MAA16758;
Tue, 11 Mar 1997 12:08:42 -0500
Message-Id: <199703111708.MAA16758 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: John Harvey <johnbob at io.com>
Cc: ietf at ietf.org
Subject: Re: call for a new email infrastructure - Not needed
In-Reply-To: Your message of "Tue, 11 Mar 1997 09:16:18 CST."
<Pine.A32.3.95.970311090035.16818A-100000 at loopback>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <Pine.A32.3.95.970311090035.16818A-100000 at loopback>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-2014313000P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 11 Mar 1997 12:08:41 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-2014313000P
Content-Type: text/plain; charset=us-ascii
On Tue, 11 Mar 1997 09:16:18 CST, John Harvey said:
> unsolicited part of the message is a small as possible, contains no
> text (not even a subject line) and can be used for filtering.
The biggest problem with the "only send a URL" scheme is that you have just
effectively made it impossible to send e-mail from a site that is behind a
firewall, or is dialup and not always connected. Also, some people pay
by-the-minute for connect time - if it's a small note (such as this one), the
actual message can be downloaded in 2-3 seconds over even a 14.4 modem, but if
you actually want to *read* the note, you then have to go through another HTTP
connection (or whatever), and possibly incur a 2-3 *minute* wait if the remote
server isn't able to respond, or the network is down, etc. Now, if you get 60
messages from a mailing list, instead of having to wait (and pay for) 3-4
minutes of "air time", you might be looking at an *hour*.
Think of being put on "hold" while using a cellular phone. Multiple times. ;)
Also, the less you include in the "wrapper", the *less* filtering you can do.
I happen to do a *LOT* of filtering based on the Subject: field, and even some
filtering based on the body...
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_-2014313000P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMyWRltQBOOoptg9JAQGo+AQAmH0KYwJv6S2DRPJtXwPqGKiZrCKOLh+G
kYeOKvbmLUv83bVMOuTbfZukr+bXq17xpq73u/PeDlNitMFZIKLtKOGxcLOv87gV
SpVoJT7gwAAKMNX4+ReIU5paTUKpg7zCS3HQfdlefPOrUkNA2YpAr+8xVBrwKAEx
AMU9cWHMevw=
=4mht
-----END PGP MESSAGE-----
--==_Exmh_-2014313000P--
Received: from ietf.org by ietf.org id aa08773; 11 Mar 97 12:22 EST
Received: from mailhost1.cac.washington.edu by ietf.org id aa08529;
11 Mar 97 12:20 EST
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
by mailhost1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW96.12) with SMTP
id JAA01099; Tue, 11 Mar 1997 09:16:53 -0800
Date: Tue, 11 Mar 1997 09:15:41 -0800 (PST)
Sender:ietf-request at ietf.org
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at tomobiki-cho.cac.washington.edu>
Subject: Re: call for a new email infrastructure
To: Valdis.Kletnieks at vt.edu
cc: Keith Moore <moore at cs.utk.edu>, ietf at ietf.org
In-Reply-To: <199703111709.MAA16794 at black-ice.cc.vt.edu>
Message-ID: <MailManager.858100541.5225.mrc at Tomobiki-Cho.CAC.Washington.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Tue, 11 Mar 1997 12:08:56 -0500, Valdis.Kletnieks at vt.edu wrote:
> I might be dense, but who will pay for the IETF mailing list under this
> model?
In the model that I envision, the act of subscribing to a mailing list would
constitute agreement to waive charges.
Received: from ietf.org by ietf.org id aa08775; 11 Mar 97 12:23 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa08362; 11 Mar 97 12:14 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id MAA16794;
Tue, 11 Mar 1997 12:09:00 -0500
Message-Id: <199703111709.MAA16794 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Mark Crispin <MRC at panda.com>
Cc: Keith Moore <moore at cs.utk.edu>, ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-Reply-To: Your message of "Mon, 10 Mar 1997 14:03:54 PST."
<MailManager.858031434.366.mrc at Ikkoku-Kan.Panda.COM>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <MailManager.858031434.366.mrc at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1332013890P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 11 Mar 1997 12:08:56 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_1332013890P
Content-Type: text/plain; charset=us-ascii
On Mon, 10 Mar 1997 14:03:54 PST, Mark Crispin said:
> But, more importantly, it's doubtful that the spammers would want their mail
> to be stamped with "bulk mail" postage, given that it would then be trivial
> for sites to toss out all bulk mail unconditionally.
I might be dense, but who will pay for the IETF mailing list under this model?
This is *not* a facetious question. I'm the postmaster of a system that runs
well over 700 different mailing lists, anywhere from 250K to 500K outbound
postings a day (we have one 4,000+ subscriber list that gets hit by up to 100
postings a day all by itself). In such a scenario, who pays?
Does the person who posted the original notice pay for all the deliveries? If
so, how does he control costs? I have *NO* idea how many IETF subscribers
there are - especially considering sub-exploders behind firewalls and the like.
If the person says "don't spend more than $0.75 US for this posting", what
happens when the money runs out? Note that you probably do *NOT* want to
enable before-posting checking of the estimated cost, for 2 reasons: (a)
simple performance and (b) it provides a nice covert channel for spammers to
evaluate high price-performance lists for their spamming..
A quick check of yesterday's SMTP logs for our Listserv machine reveals a total
of 211,800 connections, to 6,173 different hostnames. Aggregating by
second-level domain names only reduces it to 3,496 different ones (note that
this counts *everything* under 'co.uk' or 'com.au' as one site....)
Now, let's examine the implications of this. Like many organizations, Virginia
Tech has to be careful who and how we enter into contractual obligations with
(in particular, our beancounters don't like it when we get invoiced by people
we haven't sent a purchase order or other agreement in advance). We are *NOT*
going to be able to negotiate the equivalent of the X.400 PRMD/ADMD stuff with
6,000+ different remote sites, nor are we going to be able to actually settle
up with 6,000+ other sites.
The other alternative (massive interchanges that will do all that for you)
appears to be a non-starter as well. There's a scaling problem here - by the
time you narrow it down to some number X interchanges small enough that each
member of X is able to negotiate (X-1) interconnection agreements, each one has
to be able to handle 1/X'th of the *entire* Internet mail load. Ask the
people at AOL what it's like to try to handle 1/10th (or whatever it is)
of the Internet ;)
We have enough trouble building a IP routing interconnect that just swaps
packets back and forth. Imagine what would happen to MAE-East if it had
to do packet counting, message counting, message recipient filtering,
and chargebacks and settlements.....
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_1332013890P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMyWRptQBOOoptg9JAQH3VwP/b4CYFRbMlRq2m6hC3sCqsUy+/aF4OCvD
oKua6WiGQrRsad2vPqWoJpGlpXNfP0LSPESk9mSFlSySWCjKYXk3Mo8UtlOKjXOL
f7Pl4koRk9Fn8t9ZoboDa45134eGiUkH1Igm85r04f5AT4zEMXYCu3c9QQjAl4Ks
XjYHZudytwU=
=AnRF
-----END PGP MESSAGE-----
--==_Exmh_1332013890P--
Received: from ietf.org by ietf.org id aa11085; 11 Mar 97 13:08 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa10797; 11 Mar 97 13:05 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id NAA18342;
Tue, 11 Mar 1997 13:01:24 -0500
Message-Id: <199703111801.NAA18342 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Mark Crispin <MRC at panda.com>
Cc: mailcost-l at listserv.vt.edu, ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-Reply-To: Your message of "Tue, 11 Mar 1997 09:15:41 PST."
<MailManager.858100541.5225.mrc at Tomobiki-Cho.CAC.Washington.EDU>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <MailManager.858100541.5225.mrc at Tomobiki-Cho.CAC.Washington.EDU>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1337506282P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 11 Mar 1997 13:01:24 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_1337506282P
Content-Type: text/plain; charset=us-ascii
(Administrivia - I've set up a Listserv mailing list called
'mailcost-l at listserv.vt.edu' for further discussion on this. Send e-mail
to 'listserv at listserv.vt.edu' with "subscribe mailcost-l Your Name" to
subscribe. You will have to reply to an "OK' magic cookie to finish
the subscription process).
On Tue, 11 Mar 1997 09:15:41 PST, Mark Crispin said:
> In the model that I envision, the act of subscribing to a mailing list would
> constitute agreement to waive charges.
Umm.. an agreement by *whom*? If one of my users subscribes to a mailing
list, who will pay for that mail? And for that matter, who is paying whom
for person-to-person mail? Does the sender himself pay? Does the
sender's provider pay the receiver's provider, and then charge the sender?
And more importantly, how does the receiving provider "know" that an incoming
mail is a "list" posting? Does the subscriber have to do it through the
provider (careful here - think privacy considerations)? If not, how does
the receiving provider know it is "real" list mail as opposed to a spam list?
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_1337506282P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMyWd8tQBOOoptg9JAQHLHgP+M11seg0+KuVaAriQ5cbnx5BZl/KiZWta
twC/piODGOgWy8PrKoJs0P+L2pqfmU/sq2or1uSk2eL+IwimEPUTKVkMPXr3yG3B
1WoEnHPeAp/7c/6Dnje2GeoI4qE0hYm0ymzGcQYlInru9p/geMs9/kKMAKYComnd
2OIJmIJesBY=
=lPSz
-----END PGP MESSAGE-----
--==_Exmh_1337506282P--
Received: from ietf.org by ietf.org id aa12330; 11 Mar 97 13:36 EST
Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa12257;
11 Mar 97 13:34 EST
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA03583; Tue, 11 Mar 97 13:31:28 EST
Received: by dcl.MIT.EDU (5.x/4.7) id AA23330; Tue, 11 Mar 1997 13:31:22 -0500
Date: Tue, 11 Mar 1997 13:31:22 -0500
Message-Id: <9703111831.AA23330 at dcl.MIT.EDU>
Sender:ietf-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Mark Crispin <MRC at panda.com>
Cc: Valdis.Kletnieks at vt.edu, Keith Moore <moore at cs.utk.edu>, ietf at ietf.org
In-Reply-To: Mark Crispin's message of Tue, 11 Mar 1997 09:15:41 -0800 (PST),
<MailManager.858100541.5225.mrc at Tomobiki-Cho.CAC.Washington.EDU>
Subject: Re: call for a new email infrastructure
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Source-Info: From (or Sender) name not authenticated.
Date: Tue, 11 Mar 1997 09:15:41 -0800 (PST)
From: Mark Crispin <MRC at panda.com>
In the model that I envision, the act of subscribing to a mailing list would
constitute agreement to waive charges.
Ok, so how do you prevent spammers from spamming mailing lists?
One possible solution: Only allow people who are on the mailing list to
send to the mailing list. (Problems with lists that have exploders, for
people who read mailing lists via news, etc.)
A further problem: What if spammers subscribe to the mailing list, and
then send a spam?
One possible solution: Make each person sign an agreement before they
join that they won't do this. (Problems of what's legally binding, what
the sanctions are if they violate the agreement, etc.)
Moral of the story: There are no easy answers.....
- Ted
Received: from ietf.org by ietf.org id aa14636; 11 Mar 97 14:40 EST
Received: from quackerjack.cc.vt.edu by ietf.org id aa14536; 11 Mar 97 14:36 EST
Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30])
by quackerjack.cc.vt.edu (8.8.4/8.8.4) with ESMTP
id OAA28995; Tue, 11 Mar 1997 14:33:50 -0500 (EST)
Received: from [128.173.12.232] (sears.cns.vt.edu [128.173.12.232])
by sable.cc.vt.edu (8.8.4/8.8.4) with SMTP
id OAA20251; Tue, 11 Mar 1997 14:33:50 -0500 (EST)
X-Sender: sears at mail.vt.edu
Message-Id: <v02140b03af4b62662a9c at [128.173.12.232]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 11 Mar 1997 14:34:24 -0500
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Sender:ietf-request at ietf.org
From: pris sears <sears at vt.edu>
Subject: Re: call for a new email infrastructure
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
> Date: Tue, 11 Mar 1997 09:15:41 -0800 (PST)
> From: Mark Crispin <MRC at panda.com>
>
> In the model that I envision, the act of subscribing to a mailing list would
> constitute agreement to waive charges.
>
>Ok, so how do you prevent spammers from spamming mailing lists?
>
>One possible solution: Only allow people who are on the mailing list to
>send to the mailing list. (Problems with lists that have exploders, for
>people who read mailing lists via news, etc.)
yes, and use a confirmation system, ie, user sends subscribe request,
listserv sends confirmation which must be replied to to complete
subscription. this weeds out subs from fake addresses, and jokers
subscribing for someone else, as we have seen happen lately.
>A further problem: What if spammers subscribe to the mailing list, and
>then send a spam?
boot 'em off the list asap and put them on a blacklist. when the sub.
confirmation goes out, it should specifically say that offtopic/commercial
mail is prohibited and grounds for being booted permanently from the list.
i hate spam, but the only spam that really bothers me is what comes from
faked addresses and domains and cannot be traced to the sender or a
postmaster. i wouldn't mind a system where mail servers look up from
addresses to make sure they are real and dump the mail before sending to
users if they are faked. if i get spam, i can deal with it myself as long
as i can get to the person that sent it (or their isp).
postmasters sharing blacklists and denying mail by domain from serious
offenders can also be very effective. i expect mail from spamford's new
domain to be universally bit-bucketed before i ever have to look at any of
it :)
_____________________________________________________________
Thanks for your kind attention - I'm outta here!
Pris Sears | sears at vt.edu | http://sears.cns.vt.edu/ | 231-2305
Received: from ietf.org by ietf.org id aa15766; 11 Mar 97 15:06 EST
Received: from ns1.BayNetworks.COM by ietf.org id aa15583; 11 Mar 97 15:05 EST
Received: from ns1.BayNetworks.COM ([134.177.1.107])
by mailhost2.BayNetworks.COM (8.8.5/BNET-96/12/06-E) with ESMTP
id LAA25852; Tue, 11 Mar 1997 11:59:30 -0800 (PST)
for <ietf at ietf.org>
Received: from pobox.corpwest.BayNetworks.COM (mailhost.corpwest.baynetworks.com [134.177.1.95])
by ns1.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with ESMTP
id MAA25383; Tue, 11 Mar 1997 12:02:22 -0800 (PST)
for <ietf at ietf.org>
Posted-Date: Tue, 11 Mar 1997 12:02:22 -0800 (PST)
Received: from sc-mail2.corpwest.BayNetworks.com (sc-mail2-hme0.corpwest.baynetworks.com [134.177.64.102])
by pobox.corpwest.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP
id MAA24162; Tue, 11 Mar 1997 12:02:18 -0800
for <ietf at ietf.org>
Received: from java-pc (java-pc.engwest.baynetworks.com [134.177.115.78])
by sc-mail2.corpwest.BayNetworks.com (post.office MTA v2.0 0529
ID# 0-13459) with SMTP id AAA27232 for <ietf at ietf.org>;
Tue, 11 Mar 1997 12:02:17 -0800
Message-Id: <3.0.32.19970311120109.00921b30 at sc-mail2.corpwest.baynetworks.com>
X-Sender: tlavian at sc-mail2.corpwest.baynetworks.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 11 Mar 1997 12:01:10 +0000
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Tal Lavian <Tal_Lavian at baynetworks.com>
Subject: remove
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
remove
Received: from ietf.org by ietf.org id aa16058; 11 Mar 97 15:10 EST
Received: from egoshin.genesyslab.com by ietf.org id aa15950;
11 Mar 97 15:09 EST
Received: (from egoshin at localhost) by egoshin.genesyslab.com (8.8.5/8.6.9) id MAA08534; Tue, 11 Mar 1997 12:07:45 -0800
Date: Tue, 11 Mar 1997 12:07:45 -0800
Sender:ietf-request at ietf.org
From: Leonid Yegoshin <egoshin at genesyslab.com>
Message-Id: <199703112007.MAA08534 at egoshin.genesyslab.com>
To: sears at vt.edu, tytso at mit.edu
Subject: Re: call for a new email infrastructure
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
>From: pris sears <sears at vt.edu>
>>A further problem: What if spammers subscribe to the mailing list, and
>>then send a spam?
>
>boot 'em off the list asap and put them on a blacklist. when the sub.
>confirmation goes out, it should specifically say that offtopic/commercial
>mail is prohibited and grounds for being booted permanently from the list.
Yet additional problem - somebody do it as YOU. Of course, decision
is E-sign. But this decision draw another problem - we are need to maintain
multiple secret keys for multiple mail-lists etc. Do you want this deal
in connection with E-mail lists ? I am not...
More over that could you do with export restrictions on this way (just now) ?
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa16091; 11 Mar 97 15:10 EST
Received: from ns1.BayNetworks.COM by ietf.org id aa16002; 11 Mar 97 15:09 EST
Received: from ns1.BayNetworks.COM ([134.177.1.107])
by mailhost2.BayNetworks.COM (8.8.5/BNET-96/12/06-E) with ESMTP
id MAA25993; Tue, 11 Mar 1997 12:04:01 -0800 (PST)
for <ietf at ietf.org>
Received: from pobox.corpwest.BayNetworks.COM (mailhost.corpwest.baynetworks.com [134.177.1.95])
by ns1.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with ESMTP
id MAA00138; Tue, 11 Mar 1997 12:06:52 -0800 (PST)
for <ietf at ietf.org>
Posted-Date: Tue, 11 Mar 1997 12:06:52 -0800 (PST)
Received: from sc-mail2.corpwest.BayNetworks.com (sc-mail2-hme0.corpwest.baynetworks.com [134.177.64.102])
by pobox.corpwest.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP
id MAA24559; Tue, 11 Mar 1997 12:06:52 -0800
for <ietf at ietf.org>
Received: from java-pc (java-pc.engwest.baynetworks.com [134.177.115.78])
by sc-mail2.corpwest.BayNetworks.com (post.office MTA v2.0 0529
ID# 0-13459) with SMTP id AAA27862 for <ietf at ietf.org>;
Tue, 11 Mar 1997 12:06:50 -0800
Message-Id: <3.0.32.19970311120542.00949660 at sc-mail2.corpwest.baynetworks.com>
X-Sender: tlavian at sc-mail2.corpwest.baynetworks.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 11 Mar 1997 12:05:43 +0000
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Tal Lavian <Tal_Lavian at baynetworks.com>
Subject: remove
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
remove Tal_Lavian at sc-mail2.corpwest.baynetworks.com
Received: from ietf.org by ietf.org id aa16142; 11 Mar 97 15:11 EST
Received: from ns3.BayNetworks.COM by ietf.org id aa15779; 11 Mar 97 15:06 EST
Received: from ns1.BayNetworks.COM ([134.177.1.107])
by mailhost1.BayNetworks.COM (8.8.5/BNET-96/12/06-E) with ESMTP
id MAA19640; Tue, 11 Mar 1997 12:03:44 -0800 (PST)
for <ietf at ietf.org>
Received: from pobox.corpwest.BayNetworks.COM (mailhost.corpwest.baynetworks.com [134.177.1.95])
by ns1.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with ESMTP
id MAA29950; Tue, 11 Mar 1997 12:03:35 -0800 (PST)
for <ietf at ietf.org>
Posted-Date: Tue, 11 Mar 1997 12:03:35 -0800 (PST)
Received: from sc-mail2.corpwest.BayNetworks.com (sc-mail2-hme0.corpwest.baynetworks.com [134.177.64.102])
by pobox.corpwest.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP
id MAA24249; Tue, 11 Mar 1997 12:03:35 -0800
for <ietf at ietf.org>
Received: from java-pc (java-pc.engwest.baynetworks.com [134.177.115.78])
by sc-mail2.corpwest.BayNetworks.com (post.office MTA v2.0 0529
ID# 0-13459) with SMTP id AAA27384 for <ietf at ietf.org>;
Tue, 11 Mar 1997 12:03:34 -0800
Message-Id: <3.0.32.19970311120227.00921b30 at sc-mail2.corpwest.baynetworks.com>
X-Sender: tlavian at sc-mail2.corpwest.baynetworks.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 11 Mar 1997 12:02:27 +0000
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Tal Lavian <Tal_Lavian at baynetworks.com>
Subject: remove
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
remove Tal Lavian <Tal_Lavian at sc-mail2.corpwest.baynetworks.com>
Received: from cnri by ietf.org id aa16317; 11 Mar 97 15:15 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17007;
11 Mar 97 15:15 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA11684 at pad-thai.cam.ov.com>; Tue, 11 Mar 1997 18:25:15 GMT
Message-Id: <3325A2EA.69D7 at dascom.com>
Date: Tue, 11 Mar 1997 10:22:34 -0800
From: John Nunneley <johnn at dascom.com>
Reply-To: johnn at dascom.com
Organization: Dascom
X-Mailer: Mozilla 3.0Gold (Win95; I)
Mime-Version: 1.0
To: Mike Eisler <Michael.Eisler at eng.sun.com>
Cc: cat-ietf at mit.edu
Subject: Re: GSSAPI and SSL?
References: <Roam 0.9.4.858052094.26887.mre at jurassic.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Yes. That is an interesting approach. And is somewhat similiar to the
proposal from the SSL community to incorporate DCE/Kerberos suites into
SSL. But I was actually thinking of a more straightforward layering
that *would* maintain the SSL protocol on the wire for interoperability
purposes. That way I have a GSSAPI based application that can either
speak DCE or SSL - as the customer desires.
Basically, I'm just trying to get a handle on how much activity and
interest there is in GSSAPI these days. It seems like all the attention
is focused on SSL now and I should migrate my app over to that.
But then again, I keep hearing references to SSL problems wrt to
scaling, single point of failure, and susceptibility to attacks such as
replay.
- John
Mike Eisler wrote:
>
> > Is anyone looking into (or have done) integration of SSL under the
> > GSSAPI?
> > Is there any interest in the GSSAPI community in this?
> > Or do you view these things as virtually interchangeable (i.e. solves
> > the same problem)?
> > Does this even make any sense?
>
> I've had similar thoughts. One could create a GSS-API mechanism that mimiced
> SSL's CipherSuites as QOP values (using the same numerical values). And one
> could also mimic SSL's CipherSuite negotiation during the
> GSS_Init_sec_context/GSS_Accept_sec_context handshake.
>
> The value in this would be in simplifying the deployment of protocols that use
> GSS-API security into operating environments that favor SSL (for example web
> browsers). While the result would NOT be the SSL protocol, it would be
> security equivalent to what SSL delivers. Presumably, if the operating
> environment has modularized the SSL layer appropriately, the GSS-SSL
> mechanism could share code with the SSL protocol's API:
>
> internal SSL-api GSS-API
> | |
> ssl-protocol engine gss-ssl-mech
> \ /
> ssl-crypto-code
>
> -
>
> Mike Eisler
> SunSoft, Inc.
> mre at Eng.Sun.Com
--
------------------------------------------------------------------------
John Nunneley Phone: +1 408 457 4510
DASCOM Inc. Fax: +1 408 457 0710
1509 Seabright Avenue Email: johnn at dascom.com
Santa Cruz CA 95062 WWW: http://www.dascom.com/
------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa17225; 11 Mar 97 15:27 EST
Received: from ns3.BayNetworks.COM by ietf.org id aa17038; 11 Mar 97 15:25 EST
Received: from ns1.BayNetworks.COM ([134.177.1.107])
by mailhost1.BayNetworks.COM (8.8.5/BNET-96/12/06-E) with ESMTP
id MAA20305; Tue, 11 Mar 1997 12:22:18 -0800 (PST)
for <ietf at ietf.org>
Received: from lobster1.corpeast.Baynetworks.com (lobster1.corpeast.baynetworks.com [192.32.72.17])
by ns1.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with SMTP
id MAA01249; Tue, 11 Mar 1997 12:22:12 -0800 (PST)
for <ietf at ietf.org>
Posted-Date: Tue, 11 Mar 1997 12:22:12 -0800 (PST)
Received: from jgarcia.corpeast.baynetworks.com ([192.32.108.105]) by lobster1.corpeast.Baynetworks.com (4.1/SMI-4.1)
id AA14465; Tue, 11 Mar 97 15:22:12 EST
Message-Id: <3.0.32.19970311142141.006dff54 at bl-mail2.corpeast.baynetworks.com>
X-Sender: jgarcia at bl-mail2.corpeast.baynetworks.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 11 Mar 1997 14:21:42 -0600
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Jorge Garcia <jgarcia at baynetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
remove
Received: from ietf.org by ietf.org id aa18285; 11 Mar 97 15:38 EST
Received: from MAILBOX.ADM.RL.AF.MIL by ietf.org id aa18197; 11 Mar 97 15:36 EST
Received: from SHAGGY.C3D.RL.AF.MIL (SHAGGY.C3D.RL.AF.MIL [128.132.39.57]) by mailbox.adm.rl.af.mil (8.8.5/8.7.6) with SMTP id PAA20586; Tue, 11 Mar 1997 15:33:06 -0500 (EST)
Received: by SHAGGY.C3D.RL.AF.MIL with Microsoft Mail
id <01BC2E31.7E5D7320 at SHAGGY.C3D.RL.AF.MIL>; Tue, 11 Mar 1997 15:32:56 -0500
Message-ID: <01BC2E31.7E5D7320 at SHAGGY.C3D.RL.AF.MIL>
Sender:ietf-request at ietf.org
From: "C.J. Maciag" <maciagc at rl.af.mil>
To: "Theodore Y. Ts'o" <tytso at mit.edu>, 'pris sears' <sears at vt.edu>
Cc: "ietf at ietf.org" <ietf at ietf.org>
Subject: RE: call for a new email infrastructure
Date: Tue, 11 Mar 1997 15:32:55 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
>A further problem: What if spammers subscribe to the mailing list, and
>then send a spam?
>boot 'em off the list asap and put them on a blacklist...
Ahhh... A great idea. But where would we put such a blacklist? And how do we prevent
would-be spammers from adding legitimate users to the blacklist and cause denial-of-service
to legitimate subscribers. To say that only ISPs are allowed to access the list would
be shortsighted, as the operation of this (the IETF exploder) illustrates.
>i hate spam, but the only spam that really bothers me is what comes from
>faked addresses and domains and cannot be traced to the sender or a
>postmaster. i wouldn't mind a system where mail servers look up from
>addresses to make sure they are real and dump the mail before sending to
>users if they are faked. if i get spam, i can deal with it myself as long
>as i can get to the person that sent it (or their isp).
This I like even better. We have the ability to do a DNS lookup on users of other services
(e.g. Web access), why not build in this feature to mail exploders (and other post office
devices) to reject SMTP/X.400 packets from illegitimate users? I think this enhancement
could be handled with only minor modifications to the local mail server, and not to the
SMTP/X.400 protocol.
Chet
_______________________________________________________
Chester J. Maciag
Network Security Engineer
US Air Force Rome Laboratory
525 Brooks Rd, Rome NY 13441-4505
DSN 587 (315) 330-1875
maciagc at rl.af.mil
"The network itself has become a theater of operation"
Received: from ietf.org by ietf.org id aa21213; 11 Mar 97 16:15 EST
Received: from gdansk.Berkeley.EDU by ietf.org id aa21126; 11 Mar 97 16:13 EST
Received: by gdansk. (SMI-8.6/SMI-SVR4)
id NAA14923; Tue, 11 Mar 1997 13:12:15 -0800
Date: Tue, 11 Mar 1997 13:12:15 -0800
Sender:ietf-request at ietf.org
From: cclee at gdansk
Message-Id: <199703112112.NAA14923 at gdansk.>
To: ietf at ietf.org
Subject: remove
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: YfVq8ZG93T9hKQ7T7uaYzA==
Source-Info: From (or Sender) name not authenticated.
please remove cclee at gdansk.berkeley.edu
Received: from ietf.org by ietf.org id aa21522; 11 Mar 97 16:24 EST
Received: from egoshin.genesyslab.com by ietf.org id aa21466;
11 Mar 97 16:23 EST
Received: (from egoshin at localhost) by egoshin.genesyslab.com (8.8.5/8.6.9) id NAA08805; Tue, 11 Mar 1997 13:21:18 -0800
Date: Tue, 11 Mar 1997 13:21:18 -0800
Sender:ietf-request at ietf.org
From: Leonid Yegoshin <egoshin at genesyslab.com>
Message-Id: <199703112121.NAA08805 at egoshin.genesyslab.com>
To: Claudio.Allocchio at elettra.trieste.it, ietf at ietf.org
Subject: re: call for a new email infrastructure
Source-Info: From (or Sender) name not authenticated.
Here is some scetch of proposal on authentificated mail transfer.
(Unfortunately I can't attend Memphys IETF, sorry)
Advantage of it is coexistence with current SMTP.
- Leonid Yegoshin, LY22
Main flow of authentification of mail transfering.
A. TCP/IP protocol changes.
1) Sender use some additional SMTP command to setup authentification.
(alternative: use another TCP port)
2) Receiver check host address in "MAIL FROM" of SMTP to match IP address of
sender. If correct - OK, next phase. If not - check IP (DNS ?) address of
sender in trusted mail gateways list (which support authentificated mail
transfer).
3) If address was not correct - reject mail permanent.
4) Next phase: after receiving mail body receiver insert in headers some line
identified receiver itself (like Received, but with more strong syntax).
And replace some another predefined line to show authentificated
reception.
X) During non-authentificated SMTP - delete predefined line to show
non-authentificated SMTP.
B. Human procedures to support trusted authentificated E-mail gateway
infrastructure (can be changed by Internet community, of course)
1) If you receive E-mail which don't corresponent sender address via
authentificated protocol send it back to nearest gateway and wait
explanation. After receiving it/not receiving it - decide do you
want to leave this nearest gateway in trusted list.
2) If you are a trusted gateway maintainer and receive E-mail about problem
with authentification - check correctness of E-mail passed gateway
in receiver identified line (it can have crypted time/hope count).
If it correct - check previous gateway in trusted gateway list and
ask him. After receiving explanation/not receiving - decide do you
want to leave this gateway in trusted list and answer originator of
request.
3) E-mail list holder is or is NOT trusted gateway and can send E-mail
with "MAIL FROM" equal its own host address. But E-mail list holder
can check authentification and reproduce it during delivery.
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa22772; 11 Mar 97 16:50 EST
Received: from spheara.io360.com by ietf.org id aa22539; 11 Mar 97 16:47 EST
Received: (from stevek at localhost) by spheara.io360.com (8.7.6/8.6.10-io360) id QAA11036; Tue, 11 Mar 1997 16:44:15 -0500 (EST)
Message-ID: <Mutt.19970311164415.stevek at spheara.io360.com>
Date: Tue, 11 Mar 1997 16:44:15 -0500
Sender:ietf-request at ietf.org
From: Steve Kann <stevek at stevek.com>
To: Tal Lavian <Tal_Lavian at baynetworks.com>
Cc: ietf at ietf.org
Subject: Re: remove
References: <3.0.32.19970311120542.00949660 at sc-mail2.corpwest.baynetworks.com>
X-Mailer: Mutt 0.58.1
Mime-Version: 1.0
X-Blank-Header-Line: (this header intentionally left blank)
Source-Info: From (or Sender) name not authenticated.
Tal Lavian writes:
> remove Tal_Lavian at sc-mail2.corpwest.baynetworks.com
You know, Mr Lavian, that behaviour such as posting "remove" messages to
a list that has (probably) reaches thousands of the most influential
internet professionals does not look good for your company.
One wonders if this is their example of netiquette in this public forum,
then what kinds of net-unfriendly things do their routers do behind the
scenes when no one knows?
-SteveK
--
Steve Kann i/o 360 digital design 841 Broadway, Suite 502
PGP 1024/C0145E05 F2 D6 24 83 9E 52 9A 61 AA BB 97 61 5C A1 B8 CE
Personal:stevek at SteveK.COM Business: stevek at io360.com
Received: from ietf.org by ietf.org id aa23022; 11 Mar 97 16:53 EST
Received: from rover.cygnus.com by ietf.org id aa22811; 11 Mar 97 16:51 EST
Received: (from marc at localhost) by rover.cygnus.com (8.7.6/8.6.12) id QAA28102; Tue, 11 Mar 1997 16:48:56 -0500 (EST)
To: ietf at ietf.org
Subject: removing yourself
Sender:ietf-request at ietf.org
From: Marc Horowitz <marc at cygnus.com>
Date: 11 Mar 1997 16:48:55 -0500
Message-ID: <t53g1y2t7zs.fsf at rover.cygnus.com>
Lines: 17
X-Mailer: Gnus v5.3/Emacs 19.34
Source-Info: From (or Sender) name not authenticated.
let's try this again.
sending mail to the entire list doesn't get you off. instead, it
makes you look ignorant. To quote from
http://www.ietf.org/mailinglists.html:
To join the IETF general discussion list, send a request to:
ietf-request at ietf.org and enter the word subscribe in the Subject line
of the message.
To unsubscribe, send a request as described above but containing
unsubscribe in the Subject line. Note: do not attempt to subscribe or
unsubscribe by sending mail directly to the lists themselves -- this
will not result in the desired action but will irritate thousands of
list subscribers.
Marc
Received: from ietf.org by ietf.org id aa23253; 11 Mar 97 16:58 EST
Received: from www.atr.net by ietf.org id aa23048; 11 Mar 97 16:54 EST
Received: from www.atr.net (www.atr.net [206.232.44.253]) by warp.atr.net (NTMail 3.02.10) with ESMTP id ja000347 for <ietf at ietf.org>; Tue, 11 Mar 1997 16:51:42 +0000
Message-ID: <3325D3ED.7007 at atr.net>
Date: Tue, 11 Mar 1997 16:51:41 -0500
Sender:ietf-request at ietf.org
From: Turner W Rentz III <treyr at atr.net>
Reply-To: treyr at atr.net
Organization: Advance Technology and research, Inc.
X-Mailer: Mozilla 3.01 (WinNT; I)
MIME-Version: 1.0
To: Leonid Yegoshin <egoshin at genesyslab.com>
CC: ietf at ietf.org
Subject: Re: call for a new email infrastructure
References: <199703112007.MAA08534 at egoshin.genesyslab.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Info: Evaluation version at warp.atr.net
Source-Info: From (or Sender) name not authenticated.
Leonid Yegoshin wrote:
> Yet additional problem - somebody do it as YOU. Of course, decision
> is E-sign. But this decision draw another problem - we are need to maintain
> multiple secret keys for multiple mail-lists etc. Do you want this deal
> in connection with E-mail lists ? I am not...
> More over that could you do with export restrictions on this (the) way
Someone once told me the Russian Language conjugates the noun, so in
this context, the english is readable.
First -
1. Authentication
- This means that it comes from you
2. Certification
- This means that it comes from you,
and you make sure that it gets to whom
you want to send it.
Export restrictions will prohibit RSA keys greater than 40 bits.
It is my understanding that key length will go up soon.
--
T. Rentz, III "The Internet is the Garden of Eden."
Software Engineer
http://www.atr.net/people/treyr
Received: from ietf.org by ietf.org id aa23254; 11 Mar 97 16:58 EST
Received: from newra.src.umd.edu by ietf.org id aa23137; 11 Mar 97 16:56 EST
Received: from volt.isr.umd.edu (volt.isr.umd.edu [128.8.111.165])
by newra.src.umd.edu (8.8.5/8.8.5) with SMTP id QAA21362
for <ietf at ietf.org>; Tue, 11 Mar 1997 16:51:47 -0500 (EST)
X-Orig-Sender: mayssat at newra.src.umd.edu
Message-ID: <3325D3F2.167EB0E7 at isr.umd.edu>
Date: Tue, 11 Mar 1997 16:51:46 -0500
Sender:ietf-request at ietf.org
From: Mayssat Robert <mayssat at isr.umd.edu>
X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.4 sun4m)
MIME-Version: 1.0
To: ietf at ietf.org
Subject: remove
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
remove
Received: from ietf.org by ietf.org id aa23252; 11 Mar 97 16:58 EST
Received: from notes.technicalpeople.com by ietf.org id aa23138;
11 Mar 97 16:56 EST
Received: by tpi_notes.technicalpeople.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5)
id <01BC2E34.2A8AD550 at tpi_notes.technicalpeople.com>; Tue, 11 Mar 1997 15:52:04 -0600
Message-ID: <c=US%a=_%p=TPI%l=TPI_NOTES-970311215202Z-316 at tpi_notes.technicalpeople.com>
Sender:ietf-request at ietf.org
From: Kyle Hendricksen <KyleH at technicalpeople.com>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject:
Date: Tue, 11 Mar 1997 15:52:02 -0600
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
Encoding: 1 TEXT
Source-Info: From (or Sender) name not authenticated.
remove
Received: from ietf.org by ietf.org id aa23523; 11 Mar 97 17:00 EST
Received: from cannon.ecf.toronto.edu by ietf.org id aa23455;
11 Mar 97 16:59 EST
Received: by cannon.ecf.toronto.edu id <10411>; Tue, 11 Mar 1997 16:56:45 -0500
Sender:ietf-request at ietf.org
From: ARJANGPOUR SOURENA <arjangp at ecf.toronto.edu>
To: ietf at ietf.org
Subject: remove
Message-Id: <97Mar11.165645edt.10411 at cannon.ecf.toronto.edu>
Date: Tue, 11 Mar 1997 16:56:43 -0500
Source-Info: From (or Sender) name not authenticated.
please remove arjangp at ecf.toronto.edu
Received: from ietf.org by ietf.org id aa24934; 11 Mar 97 17:18 EST
Received: from asic.sec.samsung.co.kr by ietf.org id aa24886;
11 Mar 97 17:17 EST
Received: from shc.sec.samsung.co.kr ([168.219.203.8]) by asic.sec.samsung.co.kr (8.6.12h2/8.6.9) with SMTP id HAA07681 for <ietf at ietf.org>; Wed, 12 Mar 1997 07:07:01 +0900
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: shc <shchung at asic.sec.samsung.co.kr>
Subject: remove
Message-Id: SHCHUNGe6xrsz0*SHCHUNGe6xrt10*2
Date: 12 Mar 97 07:17:27
X-Priority: 3 (Normal)
X-GWSamsung-Value: 1
X-GWSamsung-StatusMsg: 0
X-GWSamsung-Trace: 1
X-GWSamsung-MsgID: SHCHUNGe6xrsz0*SHCHUNGe6xrt10*2
X-GWSamsung-PassCount: 0
X-GWSamsung-TraceInet: 1
X-GWSamsung-OrigAddress: ietf at ietf.org
X-Mailer: "Groupware E-Mail". Version 1.02.050
Mime-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Source-Info: From (or Sender) name not authenticated.
[Mailer: "Groupware E-Mail". Version 1.02.050]
please remove shchung at asic.sec.samsung.co.kr
-------------------------------------------------------------------=
--
SUNG-HYUN CHUNG
ASIC CENTER, CTO, SUWON COMPLEX
Tel) 82-331-200-3420 Fax) 82-331-200-3122
E-mail) shchung at asic.sec.samsung.co.kr
-------------------------------------------------------------------=
--=
Received: from cnri by ietf.org id aa27118; 11 Mar 97 17:56 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21202;
11 Mar 97 17:56 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA17856 at pad-thai.cam.ov.com>; Tue, 11 Mar 1997 20:52:58 GMT
To: Mike Eisler <Michael.Eisler at eng.sun.com>
Cc: johnn at dascom.com, cat-ietf at mit.edu
Subject: Re: GSSAPI and SSL?
References: <Roam 0.9.4.858052094.26887.mre at jurassic.eng.sun.com>
From: Marc Horowitz <marc at cygnus.com>
Date: 11 Mar 1997 15:52:38 -0500
In-Reply-To: Mike Eisler's message of Mon, 10 Mar 1997 19:48:14 -0800 (PST)
Message-Id: <t53lo7utall.fsf at rover.cygnus.com>
Lines: 51
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
Mike Eisler <Michael.Eisler at eng.sun.com> writes:
>> I've had similar thoughts. One could create a GSS-API mechanism
>> that mimiced SSL's CipherSuites as QOP values (using the same
>> numerical values). And one could also mimic SSL's CipherSuite
>> negotiation during the GSS_Init_sec_context/GSS_Accept_sec_context
>> handshake.
>>
>> The value in this would be in simplifying the deployment of
>> protocols that use GSS-API security into operating environments
>> that favor SSL (for example web browsers). While the result would
>> NOT be the SSL protocol, it would be security equivalent to what
>> SSL delivers. Presumably, if the operating environment has
>> modularized the SSL layer appropriately, the GSS-SSL mechanism
>> could share code with the SSL protocol's API:
>>
>>
>> internal SSL-api GSS-API
>> | |
>> ssl-protocol engine gss-ssl-mech
>> \ /
>> ssl-crypto-code
I've had similar thoughts to Mike's but I'd splice it in somewhat
differently. SSL has two advantages. From an application author's
point of view, you have a sockets-like api which implements a secure
channel. From a security point of view, you have a deployed key
infrastructure (which is somewhat fragmented and incomplete, but
between netscape, verisign, and RSA, it's getting somewhere):
internal ssl api
|
x.509 + sockets
I would add gssapi in there as a cryptosuite:
internal ssl (tls) api
|
(gssapi, x.509) + sockets
|
x.509-ssl, kerberos, spkm, whatever
This would let new and old ssl apps continue to work together. A pair
of new ssl apps could use any gssapi mechanism instead of x.509
certificates. Also, apps which didn't want to use ssl could still
take advantage of the key management infrastructure (mainly the
widely-known commercial CA's) growing up around SSL.
Adding gssapi here would be very similar to Ari's kerberos draft.
Marc
Received: from ietf.org by ietf.org id aa27989; 11 Mar 97 18:07 EST
Received: from atlas.xylogics.com by ietf.org id aa27759; 11 Mar 97 18:04 EST
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 SAA06099; Tue, 11 Mar 1997 18:00:48 -0500 (EST)
Received: by huey.xylogics.com id AA16863 (4.1/UK-doug-951219);
Tue, 11 Mar 97 18:00:48 EST
Sender:ietf-request at ietf.org
From: Gary Scott Malkin <gmalkin at xylogics.com>
Date: Tue, 11 Mar 97 18:00:48 EST
Message-Id: <16863.9703112300 at huey.xylogics.com>
To: stevek at stevek.com
Cc: Tal_Lavian at baynetworks.com, ietf at ietf.org
In-Reply-To: Steve Kann's message of Tue, 11 Mar 1997 16:44:15 -0500 <Mutt.19970311164415.stevek at spheara.io360.com>
Subject: remove
Source-Info: From (or Sender) name not authenticated.
Sorry Steve, but I feel compelled to defend my company. Lots of
idiots unsubscribe to the main list and nobody ever blames their
company for that. No company is populated entirely by wisened
network guru's and every company has its share of idiots. Just
look at the rash of unsubscribes which follow every message
telling people how to unsubscribe properly.
Don't forget that your message (OK, and this one) could be
considered spam too!
> You know, Mr Lavian, that behaviour such as posting "remove" messages to
> a list that has (probably) reaches thousands of the most influential
> internet professionals does not look good for your company.
>
> One wonders if this is their example of netiquette in this public forum,
> then what kinds of net-unfriendly things do their routers do behind the
> scenes when no one knows?
----------------------------------------------------------------------
Gary Malkin Cheap, Fast, Good
(508) 916-4237 Pick two!
Received: from ietf.org by ietf.org id aa29387; 11 Mar 97 18:20 EST
Received: from noc.msc.edu by ietf.org id aa29286; 11 Mar 97 18:18 EST
Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324))
id AA12914; Tue, 11 Mar 97 17:15:56 -0600
Sender:ietf-request at ietf.org
From: Tim Salo <salo at msc.edu>
Received: (salo at localhost) by uh.msc.edu (8.7.1/8.6.6) id RAA23372; Tue, 11 Mar 1997 17:15:56 -0600 (CST)
Date: Tue, 11 Mar 1997 17:15:56 -0600 (CST)
Message-Id: <199703112315.RAA23372 at uh.msc.edu>
To: Tal_Lavian at baynetworks.com, stevek at stevek.com
Subject: Re: remove
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
> Date: Tue, 11 Mar 1997 16:44:15 -0500
> From: Steve Kann <stevek at stevek.com>
> To: Tal Lavian <Tal_Lavian at baynetworks.com>
> Cc: ietf at ietf.org
> Subject: Re: remove
>
> Tal Lavian writes:
> > remove Tal_Lavian at sc-mail2.corpwest.baynetworks.com
>
> You know, Mr Lavian, that behaviour such as posting "remove" messages to
> a list that has (probably) reaches thousands of the most influential
> internet professionals does not look good for your company.
If this were a rare event, one might be justified in suspecting pilot error.
However, given the fairly regular rate at which "remove" messages are
submitted to this mail list, (followed by a bunch of "don't do that"
messages), one should probably dig a bit deeper for an explanation.
Perhaps, the "thousands of the most influential internet professionals"
ought to be a bit embarrassed at having developed technology which is
repeatedly demonstrated to have such poor usability characteristics.
Only half in jest,
-tjs
Received: from cnri by ietf.org id aa00883; 11 Mar 97 18:41 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22173;
11 Mar 97 18:41 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <VAA19564 at pad-thai.cam.ov.com>; Tue, 11 Mar 1997 21:33:15 GMT
Message-Id: <3325CF7F.3EF6 at trsvr.tr.unisys.com>
Date: Tue, 11 Mar 1997 16:32:47 -0500
From: Bill Buffam <bjb at trsvr.tr.unisys.com>
Reply-To: bjb at trsvr.tr.unisys.com
Organization: Unisys
X-Mailer: Mozilla 3.0Gold (WinNT; I)
Mime-Version: 1.0
To: cat-ietf at mit.edu, CryptoAPI at listserv.msn.com, ssl-talk at netscape.com
Subject: SSL underneath GSS-API/SSPI (again)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
There has been some interesting discussion over the last few days, on
both ssl-talk and cat-ietf, on the subject of putting SSL underneath
GSS-API. Opinions were all over the map: =94yes, you could do that, but
why would you want to?=94 - =94we tried it, but we had to make a lot of
assumptions in SSL and it wasn't useful=94 - =94we really want to decoupl=
e
our applications from the underlying mechanism=94.
In Microsoft's Security Design review (Sept 96), they presented an
architectural picture with SSL sitting alongside Kerberos (and NTLM and
other mechanisms) underneath GSS-API (or rather, Microsoft's SSPI
equivalent). Yet Eric Murray tells us he's already tried that and it was
essentially a failure.
I'd be very interested in hearing Microsoft comment on Eric's
experience, and for them to tell us how things are going with the
SSL-under-SSPI development.
Meanwhile, my own view is that it makes little sense to impose
mechanism-specific APIs on applications. There is a lot of benefit to
having an API that runs over multiple mechanisms. (And yes, I'm aware of
the idealized view that applications should call DCOM or RPC, and the
mechanism interface is below that - but there are many situations
(probably mostly legacy c/s interactions) where that model won't work.)
It seems to me that there are, in general, two interfaces needed for the
average GSS mechanism - one for applications, one for management. The
management API is used to set policy, and therefore must be
mechanism-specific (for example, such policy issues would be, in SSL,
cipher-suite/QoS mappings, key exchange mechanism, and any other
mechanism-specific aspect of behavior that most applications would not
want to have to bother with).
I'm somewhat surprised by how little traffic this topic has generated.
To me, it looks like a real disaster if GSS apps currently using
Kerberos have to be rewritten to some ad hoc interface on top of SSL,
(or whatever the next mechanism is) rather than have the new mechanisms
sit underneath the old interface.
BTW, if anyone wants a summary of messages on this thread to date, I
collected most of them at
http://www.chesco.com/~buffam/Security/Articles/gss-ssl.txt
--=20
Bill Buffam
Unisys, Malvern PA
bjb at trsvr.tr.unisys.com
Received: from ietf.org by ietf.org id aa03867; 11 Mar 97 19:37 EST
Received: from quackerjack.cc.vt.edu by ietf.org id aa03786; 11 Mar 97 19:35 EST
Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30])
by quackerjack.cc.vt.edu (8.8.4/8.8.4) with ESMTP
id TAA09011 for <ietf at ietf.org>; Tue, 11 Mar 1997 19:32:24 -0500 (EST)
Received: from [128.173.34.111] (as5200-1.sl037.cns.vt.edu [128.173.34.111])
by sable.cc.vt.edu (8.8.4/8.8.4) with SMTP
id TAA30969 for <ietf at ietf.org>; Tue, 11 Mar 1997 19:32:22 -0500 (EST)
Date: Tue, 11 Mar 1997 19:32:22 -0500 (EST)
X-Sender: sears at mail.vt.edu
Message-Id: <v01540b0211084bfa6fb2 at [128.173.34.111]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: pris sears <sears at vt.edu>
Subject: Re: all these 'remove's
Source-Info: From (or Sender) name not authenticated.
I think sending personal email to help the hapless soul that wants to be
removed would be more effective than sending instructions to the list - the
general list already knows how, and the spammed-out user trying to get off
the list probably is just deleting everything from it and not seeing those
unsub instructions sent to the list.
This list seems to be the victim of someone stealing email addresses and
forging subscriptions for other people, maybe it is time to start saving
subscribe requests and checking headers to see if it is all coming from one
place, and/or implement a reply-required subscription?
Here's my boilerplate to send to the individual when I see unsubs on this list:
-------
some joker must have signed you up to the ietf list -
here is how to get off the list, taken from this web page:
http://www.ietf.org/mailinglists.html:
To join the IETF general discussion list, send a request to:
ietf-request at ietf.org and enter the word subscribe in the Subject line
of the message.
Substitute unsubscribe in the above instructions to leave the list. Note:
do not attempt to subscribe or unsubscribe by sending mail directly to the
lists themselves.
good luck!
------
Might also change the subject line to something catchy like "How to get off
the list!"
---------------------------------------------------
pris sears*http://128.173.12.232/*sears at vt.edu*
Received: from cnri by ietf.org id aa04338; 11 Mar 97 19:48 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23183;
11 Mar 97 19:48 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <WAA22974 at pad-thai.cam.ov.com>; Tue, 11 Mar 1997 22:51:00 GMT
Date: Tue, 11 Mar 1997 16:50:47 -0600
Message-Id: <199703112250.QAA27942 at pembroke.ctd.anl.gov>
From: Doug Engert <DEEngert at anl.gov>
To: cat-ietf at mit.edu
Cc: authtf at es.net
Subject: Usage of the Kerberos 5 Transited Field
Precedence: bulk
I have a concern about the use of the Transited field of the
Kerberos 5 ticket. "draft-ietf-cat-kerberos-pk-cross-00.txt" and
"draft-ietf-cat-kerberos-pk-init-02.txt" both propose to add the names
of the certifiers in the certification path to the transited field of
the ticket. This is all well and good, but imposes additions
problems on current implementations.
RFC-1510 states in section 1.1: "...the hierarchical organization
allows an authentication path to be easily constructed. If a
hierarchical organization is not used, it may be necessary to consult
some database to construct an authentication path between realms."
And it also states: "It is important for the end-service to
know which realms were transited when deciding how much faith to place
in the authentication process". Thus the end-service will enforce some
policy based on its knowledge of which realms should be listed in the
transited field.
Most implementations of Kerberos use a default hierarchy defined by
the realm names of the client and end-service. This is used by the
client to obtain the necessary tickets, and is used by the
end-service to define the policy to be used for checking for an acceptable
authentication.
Here are my concerns:
o RFC-1510 does not state how a hierarchy is to be generated, and
there are a number of ways to do this. Most kerberos implementations
use the client and end-service realm names, and parse them in DNS
style. OSF/DCE uses the client and end-service realm names, but uses a
different separator character, and parses in the other direction. Thus
both are within the RFC specifications, but cross-realm authentication
is possible only when the two realms share an inter-realm
key. i.e. the transited field is null, and there is no problem with
determining the hierarchy between the two realms.
o When "pk-cross" and/or "pk-init" are implemented, most current
implementations of Kerberos will fail to function unless they are
modified to recognize a new policy, and not rely on the hierarchy
based on the realm names. In fact, even when the client and
end-service are with in the same realm, the transited field may
contain an entry if "pk-init" was used, and current end-services may
not accept this.
o RFC-1510 implies that the end-service should check the transited
field. But in most implementations, the intermediate TGSs also check
the transited field. When using the hierarchical approach this is
trivial, since it is easy to generate the same hierarchy from the
client and end-service realm names. But if "pk-init" and/or "pk-cross"
add additional entries to the transited filed, then each intermediate
KDC must know what policies are valid between the client and end-service.
o RFC-1510 does not require a TGS to check the transited field, it
only says an end-service should.
Here is what I would like to see changed:
o RFC-1510 or "pk-init" state that a TGS will always check the
transited field against the realm's policy before issuing a ticket
for an end-service in its realm.
This relieves the end service of having to check the policy itself if
it is willing to live with the realm's policy, although it is still
free to check it. This will simplify the the end-service processing,
and maintenance of any policy information which is now localized to the
TGSs.
This also says the the TGS does not need to check the transited field
when issuing a ticket for another realm. The only tickets issued for
another realm are for the other realm's TGS when doing cross-realm
authentication. This relieves the intermediate realm's TGS of having
to know (and enforce) the policy of the end-service's realm. It is
still free to do so, but unless the policy database is kept up to
date, it might interfere in some situations.
o The KRB_TGS_REP message be extended to allow for the client's TGS
to return, in addition to a ticket for the "closest" realm, an
authentication path which should be used to obtain the tickets to get
to the end-service's realm. (See RFC-1510 Section 3.3.3.)
Without this, either the client has to (1) rely on a hierarchy path
model of authentication, (2) maintain a configurable authentication
path table, or (3) rely on each of the intermediate TGS's to know the
path to the end-service's realm.
(1) Has the problem as stated above that different implementations of
kerberos have implemented the notion of a hierarchy differently. (2)
Has the maintenance problem of having this table on the client. (3)
Has the problem of the intermediate TGS's having to know the path to
the end-server's TGS.
Conclusion
The MIT Kerberos V5-1.0 release has the configurable authentication
path code which implements non-hierarchical authentication paths which
can be used to solve the above problems, but it suffers from a
maintenance view-point, and requires intermediate realms to also
maintain the authentication paths to all the other realms.
These two changes as outlined above, remove the responsibility of the
client, end-service and intermediate TGS's of having to know or to
check authentication paths. They place the responsibility on the
client's TGS to supply the path to the end-service's realm, and for
the end-service's TGS to check the authentication path. The changes
also streamline the processing, reduce the maintenance and allow for
the handling of the additional information being proposed by "pk-init"
and "pk-cross".
--
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Received: from ietf.org by ietf.org id aa05475; 11 Mar 97 20:23 EST
Received: from skyweyr.com by ietf.org id aa05325; 11 Mar 97 20:20 EST
Received: from [128.2.98.8] (SEUSS.RES.CMU.EDU [128.2.98.8])
by skyweyr.com (8.8.4/8.8.4) with ESMTP
id RAA12522 for <ietf at ietf.org>; Tue, 11 Mar 1997 17:17:32 -0800 (PST)
X-Sender: josh at grinch.res.cmu.edu
Message-Id: <v0302092daf4bb18e8bd7 at [128.2.98.8]>
In-Reply-To: <199703112315.RAA23372 at uh.msc.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-URL: http://thelorax.skyweyr.com/josh.html
X-Planation: My mountain is waiting...
Date: Tue, 11 Mar 1997 20:06:47 -0500
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: "Joshua D. Baer" <josh at skyweyr.com>
Subject: Stopping "remove" messages (was "Re: remove")
Source-Info: From (or Sender) name not authenticated.
At 6:15 PM -0500 3/11/97, Tim Salo wrote:
> Perhaps, the "thousands of the most influential internet professionals"
> ought to be a bit embarrassed at having developed technology which is
> repeatedly demonstrated to have such poor usability characteristics.
If it makes anyone feel better, we're currently working on an Internet
draft for a set of headers to make this less common. The hope is to enable
client software to provide useful UI's for handling list mail. More
discussion is taking place on the List Headers Mail List:
<URL:mailto:list-header at arpp.carleton.ca?subject=subscribe>
Feel free to join in!
~Josh
-- ----------------------------------
Joshua D. Baer
SkyList Mailing List Hosting Service
http://cgi.skyweyr.com/Guest.Login
Received: from cnri by ietf.org id aa06497; 11 Mar 97 20:51 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24104;
11 Mar 97 20:51 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <XAA25447 at pad-thai.cam.ov.com>; Tue, 11 Mar 1997 23:50:36 GMT
Message-Id: <3325EF0E.F42 at dascom.com>
Date: Tue, 11 Mar 1997 15:47:26 -0800
From: John Nunneley <johnn at dascom.com>
Reply-To: johnn at dascom.com
Organization: Dascom
X-Mailer: Mozilla 3.0Gold (Win95; I)
Mime-Version: 1.0
To: Mike Eisler <Michael.Eisler at eng.sun.com>
Cc: cat-ietf at mit.edu, ssl-talk at netscape.com
Subject: Re: GSSAPI and SSL?
References: <Roam 0.9.4.858108835.28738.mre at jurassic.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Mike -
Thank you for the informative and helpful response.
I guess I am just demonstrating my ignorance of both GSS-API and SSL. I
had assumed from my casual investigation that GSS-API was ("just") an
API and that it was fully intended for developers to provide specific
mechanisms (such as Kerberos and SSL) underneath. Further, I'd thought
that the tokens were completely opaque to the application and were
mechanism specific - i.e. it is the role of the specific mechanism to
determine how the authentication/integrity/privacy gets implemented, as
SSL does.
I've also gathered from related postings that Microsoft is attempting
something similiar - i.e. a GSS-API w/ SSL and Kerberos and other things
underneath. I suppose I'll need to track what's going on with that
side. Does the MS GSS-API (SSI) have any resemblance to GSS-API?
Anybody got a spare pointer?
I'm also not sure what SASL is that you refer to?
Judging from the excellent summation of the discussion so far Bill
Buffman made, I suspect I'm not the only one suffering from confusion on
this point.
Thanks, John
*************
Mike Eisler wrote:
>
>
> The philosophy of GSS-API is that it creates tokens that the application
> has the freedom to package and transport between network peers as it
> wishes. SSL on the other hand specifies how the transport of signed and/or
> encrypted data works. So any layering you produce has to reconcile the
> two different philosophies. Effectively, you'd have to design a uniform
> protocol for how GSS-API tokens get transported, and also extend your
> application's protocol to switch among GSS-API, SSL, and no security:
>
> generic security layer
> / \
> SSL protocol for encapsulating GSS-API
> | | \
> | | GSS-API
> | |
> --------------------------------------------------------------------
> application protocol (with extensions for switching
> between SSL, GSS-API encapsulation,
> and no security).
>
> I haven't looked at SASL, but I suspect SASL would work as a way to extend
> most application protocols to switch among security frameworks. Alternatively,
> one could do something like the extensions to FTP for adding GSS-API and SSL.
> Your mileage will vary depending on the application protocol.
>
> The above looks sufficiently cumbersome (I know of at least one attempt to
> make it work that was abandoned) to make me want to have my application
> protocols use either just SSL (so in your case, take a look at the ID for
> adding Kerberos V5 to SSL), or GSS-API. Alternatively, wait for IPSEC. I
> think Dan McDonald of SunSoft (danmcd at Eng.Sun.Com) has put together, or is in
> the process of putting together some IDs (for the Informational track) for an
> API to IPSEC.
>
> For my application, ONC RPC, I picked GSS-API (see
> draft-ietf-oncrpc-rpcsec_gss-02.txt), simply because RPC already had support
> for encapsulating security parameters and I saw little need to use SSL's
> (politics isn't a good reason to do something redundant). And IPSEC
> authentication doesn't work well with RPC. If I need SSL security, I'll use a
> GSS-SSL mechanism or an equivalent. Personally, I see RPC as the preferred way
> to create new secure protocols that don't want to wait for IPSEC or can't use
> IPSEC, but obviously I have a bias (note affiliation below).
>
> As to the activity around GSS-API, there's quite a bit. For example, I have in
> my hand a white paper from Microsoft that details their use of GSS-API under
> NT 5.0.
>
> -Mike Eisler
> Solaris NFS Group, SunSoft, Inc.
> mre at Eng.Sun.Com
>
--
------------------------------------------------------------------------
John Nunneley Phone: +1 408 457 4510
DASCOM Inc. Fax: +1 408 457 0710
1509 Seabright Avenue Email: johnn at dascom.com
Santa Cruz CA 95062 WWW: http://www.dascom.com/
------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa07060; 11 Mar 97 21:17 EST
Received: from external2.oc.com by ietf.org id aa07002; 11 Mar 97 21:16 EST
Received: from ocs2437.oc.com (d215-120.oc.com [192.82.215.120]) by oc.com (8.8.4/8.7.5) with SMTP id UAA10635; Tue, 11 Mar 1997 20:12:42 -0600 (CST)
Message-Id: <3.0.1.32.19970311201302.00e88668 at mailhost.oc.com>
X-Sender: cvg at mailhost.oc.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 11 Mar 1997 20:13:02 -0600
To: Tim Salo <salo at msc.edu>, Tal_Lavian at baynetworks.com, stevek at stevek.com
Sender:ietf-request at ietf.org
From: Cleve Graves <cvg at oc.com>
Subject: Re: remove
Cc: ietf at ietf.org
In-Reply-To: <199703112315.RAA23372 at uh.msc.edu>
Mime-Version: 1.0
Content-Type: text/enriched; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Source-Info: From (or Sender) name not authenticated.
As one of many list member 'lurkers' who don't post here often, but read
these discussions with great interest, I would like to suggest that Tal
is very likely correct in his view. I read the recent thread
<underline>"REMOVE" function</underline> with interest, smiles and
ultimately disappointment. Here we are supposed to be leaders in the
Internet community, and we can't take a simple action suggestion at face
value and implement it. OK! we are supposed to discuss it, but shouldn't
we DO SOMETHING when we get through discussing it?
I am very proud of the tremendous success we have achieved with the
Internet and it's technologies, but I think we need to recognize the
success has brought with it a greater responsibility for us. We've
spoken of the "Internet toaster" in the past on this list (many IPV*
threads) and we have succeeded to the point where Internet appliances ARE
being sold today at Sears, and family electronics stores everywhere
(WEBTV) with more to come. =20
What I feel we "leaders" need to do is raise our sights and recognize
that we got what we wanted, and accept the responsibility for making the
World Wide utility, which has something for EVERYONE, and more of these
users are joining us everyday. We must begin to assume and know that
MOST users today are not technical! AND it is those users we courted and
set about to attract when we started making the Internet. I feel we can
no longer approach user interface and usability issues with RTFM (read
the freakin' manual) responses. When we ignore the clear fact that our
users ARE GOING TO SEND REMOVE AND UNSUBSCRIBE messages to the list,
making those message work to actually get them off the list (and
subscribe them, too!) seems the be a clear "got to be done" sooner or
later REALITY! What has amazed me is that as leaders, we continue to
take the "later" approach.
Of all the discussion I re-read about this issue there seems to be two
general areas the discussions to fall into. One area is give them more
technology to use (we can't help it we are technology people).=20
Unfortunately these ideas all seem to boil down to give them new things
to read like appends and URL/headers (more RTFM) and when you know that
the guy with his remote on a webtv box will be one of those people trying
to get off.... HE AIN'T GONNA READ NOTHIN'!
The other area of discussion was about why we CAN'T just make the remove
message work! Actually, on closer review the discussion were about why
we couldn't make it work PERFECTLY! (another technical person trait
perfectionism). And if we can't make it work perfectly, then obviously
we should not do it. This too amazes me because I've NEVER gotten a
program that work perfectly the first time! As a technical person, I
expect BUGS, and know that as problems arise they will be addressed and
things will get better. ALL PROGRAMS WORK THIS WAY! In our
business(technology) we always ship a wine(programs) before its time! IN
FACT WE MUST... it is the only way to find out how REAL PEOPLE will use
what we create, then we make it work. The really successful programs are
the ones, which work the way the real users tell the programmers it
should work. In our case the REAL PEOPLE out there have sent us a clear
"how-it-should-work" message. If I send you a message saying to REMOVE
me, then take me of the list! Don't send the message to everyone and
don't expect me to RTFM, and don't expect that I'll read your flippin'
mail (RYFM) about how to do it right either.
So why don't we put a "remove/unsubscribe" filter in, monitor what it
takes out and doesn't take out, correct problems, and make out listserver
a model for what to expect a listserver to do now that we have Internet
toaster and "toaster USERS". And let us not forget that USER always has
been and always will be a four letter word.... Thank god, for what would
we be doing without them? =20
=09
Thanks for the many hours of great reading....
Cleve Graves
----------------------------------------------------
Off the router, onto the bridge, down
the firewall, nothin' but 'Net!!
----------------------------------------------------
At 05:15 PM 3/11/97 -0600, Tim Salo wrote:
>> Date: Tue, 11 Mar 1997 16:44:15 -0500
>> From: Steve Kann <<stevek at stevek.com>
>> To: Tal Lavian <<Tal_Lavian at baynetworks.com>
>> Cc: ietf at ietf.org
>> Subject: Re: remove
>>=20
>> Tal Lavian writes:
>> > remove Tal_Lavian at sc-mail2.corpwest.baynetworks.com
>>=20
>> You know, Mr Lavian, that behaviour such as posting "remove" messages
to
>> a list that has (probably) reaches thousands of the most influential
>> internet professionals does not look good for your company.
>
>If this were a rare event, one might be justified in suspecting pilot
error.
>However, given the fairly regular rate at which "remove" messages are
>submitted to this mail list, (followed by a bunch of "don't do that"
>messages), one should probably dig a bit deeper for an explanation.
>
>Perhaps, the "thousands of the most influential internet=20
professionals"
>ought to be a bit embarrassed at having developed technology which is
>repeatedly demonstrated to have such poor usability characteristics.
>
>Only half in jest,
>
> -tjs
>
Thanks,
----------------------------------------------------
Off the router, onto the bridge, down
the firewall, nothin' but 'Net!!
----------------------------------------------------
Cleve
Received: from cnri by ietf.org id aa10161; 11 Mar 97 22:41 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa25704;
11 Mar 97 22:41 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <CAA00454 at pad-thai.cam.ov.com>; Wed, 12 Mar 1997 02:08:18 GMT
Message-Id: <640796DB4262D0118D3300805FD4EFCF93DC3B at RED-32-MSG.dns.microsoft.com>
From: Peter Brundrett <petebr at microsoft.com>
To: "'cat-ietf at mit.edu'" <cat-ietf at mit.edu>
Subject: Optimistic snego
Date: Tue, 11 Mar 1997 17:53:40 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Precedence: bulk
I realize this is late in the review cycle for the snego-02 draft, but
would like to suggest the following proposal which may be of general
interest.
The requirement is to add support in the snego protocol that takes
advantage of an optimistic negotiation outcome. For many environments,
the preferred mechanism will be configured the same on both initiator
and target systems. Negotiation is still important in those
environments beacuse the negotiation mechanism list supports interaction
with services used less frequently that require a different mechanism,
perhaps from an older platform.
We would like to add an optional attribute to the negTokenReq for
environments where initiator and target are likely to be configured to
have the same preferential order of multiple security mechanisms. The
initiator should have the option of providing the initial security token
for the preferred mechanism piggybacked with the list of supported
mechanisms. The preferred mechanism is the first item in the mechanism
list.
The primary advantage of including the initial security token of the
preferred mechanism is that if the target preferred mechanism matches
the initiators preferred mechanism, no additional roundtrips are
incurred by using the negotiation protocol. Adding the initial security
token takes advantage of an optimistic outcome of the negotiation
without reducing security.
The initial security token from the desired mechanism of the initiator
is included in the negTokenRep.
Specific changes to the negotiation token in Section 4.2
MechType ::= OBJECT IDENTIFIER
MechTypeList ::= SEQUENCE OF MechType
NegTokenReq ::= SEQUENCE {
mechTypes[0] MechTypeList,
desiredToken[1] OCTET STRING OPTIONAL
}
The desiredToken is an optional field in the request that all target
implementations would not have to support. However for those targets
that do support piggybacking the initial desiredToken, an optimistic
negotiation response is also possible.
The negotiation procedure described in section 3.2 would add the
following optional behavior [in brackets]:
b) the initiator GSS-API implementation emits a negotion token
containing the set of supported security mechanism for the credentials
used for this context establishment, [and optionally the initial
security token for the preferred mechanism,] and indicates
GSS_CONTINUE_NEEDED status;
d) The GSS-API target deposits the token through invoking
GSS_Accept_sec_context. The target GSS-API implementation emits a
negotiation token containing which if any of the proposed mechanisms it
supports (or has selected).
[
If the preferred mechanism selected by the target matches the preferred
mechanism identified by the initiator and the initiator provides a
desiredToken, the target also deposits the desiredToken as the initial
token to GSS_Accept_sec_context for that mechanism. If the specific
mechanism GSS_Accept_sec_context is successful, the negotiation token
response contains the initial security token from that mechanism;
]
Section 5 provides examples of Security negotiation mechanism. The
additional subsection describes negotiation with initial context info.
5.4 Successful Negotiation with preferred mechanism info
(I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2),
and two options for GSS-MECH2 : OPTION1, identified by GSS-MECH2-
OPTION1 and OPTION2, identified by GSS-MECH2-OPTION2.
(I) invokes GSS_Init_sec_context() with :
Input
mech_type = OID for negotiation mechanism or NULL, if the
negotiation mechanism is the default mechanism.
Output
major_status = GSS_CONTINUE_NEEDED
output_token = negTokenReq
The negotiation token (negTokenReq) contains three security mechanisms
with :
mechType = GSS-MECH1 or
mechType = GSS-MECH2-OPTION1 or
mechType = GSS-MECH2-OPTION2
desiredToken = output_token from GSS_Init_sec_context( first
mechType) as described in [1]
(I) sends to (T) the negotiation token.
(T) supports GSS-MECH1.
(T) receives the negotiation token (negTokenReq) from (I)
(T) invokes GSS_Accept_sec_context() with :
Input
input_token = negTokenReq
Output
major_status = GSS_CONTINUE_NEEDED
output_token = negTokenRep
The negotiation token (negTokenRep) contains :
negResult = accept (the negotiation result)
supportedMech : mechType = GSS-MECH1
MechSpecInfo = output_token from GSS_Accept_sec_context(
desiredToken )
(T) returns the negotiation token (negTokenRep) to (I)
(I) invokes GSS_Init_sec_context() with :
Input
input_token = negTokenRep
Output
major_status = GSS_COMPLETE or GSS_CONTINUE_NEEDED as needed
output_token = initialContextToken (initial context token
for GSS-MECH1)
mech_type = GSS-MECH1
Specific implementations of the protocol can support the optimistic
negotiation by completing the security context establishment using the
agreed upon mechanism as described in [1].
Received: from ietf.org by ietf.org id aa18410; 12 Mar 97 3:31 EST
Received: from otherguy.gte.net by ietf.org id aa18274; 12 Mar 97 3:24 EST
Received: from dfw73150.gte.net (dfw73150.gte.net [206.124.73.150]) by smtp.gte.net (SMI-8.6/) via SMTP id CAA04285; Wed, 12 Mar 1997 02:18:03 -0600
Received: by dfw73150.gte.net with Microsoft Mail
id <01BC2E89.EFAC6060 at dfw73150.gte.net>; Wed, 12 Mar 1997 02:06:02 -0600
Message-ID: <01BC2E89.EFAC6060 at dfw73150.gte.net>
Sender:ietf-request at ietf.org
From: Stu McClure <smcclure at gte.net>
To: Keith Moore <moore at cs.utk.edu>,
'Andre Correa' <andre at tucows.alphanet.com.br>
Cc: Kent Crispin <kent at songbird.com>, "MRC at panda.com" <MRC at panda.com>,
"ietf at ietf.org" <ietf at ietf.org>
Subject: RE: call for a new email infrastructure
Date: Tue, 11 Mar 1997 22:41:59 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Source-Info: From (or Sender) name not authenticated.
Andre,
I am one of the original members of the U.S. Defense Department TCP/IP =
Application development teams from the 1970's.
Your comments demonstrate a refreshing bit of common sense and =
innocence that reminds me of our brainstorming and design sessions when =
we created this infrastructure in the first place.
Thanks for your wisdom and your contribution. I hope they listen.
Stu McClure...
----------
From: Andre Correa
Sent: Tuesday, March 11, 1997 7:00 AM
To: Keith Moore
Cc: Kent Crispin; MRC at panda.com; ietf at ietf.org
Subject: Re: call for a new email infrastructure=20
Hello, I have no idea how this mails from IETF came to me, anyway
I have an opinion about it all: (and it is good to be here)
I use and work with Internet for 3 years and I received a little
number of unwanted mails, maybe, I am a luck guy, but I dont want to pay =
to send or to receive mails, I want it to stay the way it is. Why dont
create this service of "mesage center" for those who want to have their
mails filtred, this guys will pay for the service of filtering their
e-mail...
Other thing, what we will gonna do with the large mailling lists??
Who will pay to send this mails for tousands of users??
My way looks better for me. Till now the Internet was a free field
and must continue this way!!! We must find and make something realy =
strong
and definitive with the bombers and guys that send unwanted mails.
Anyway this is just my opinion...
[]s.
<Andre>
Received: from ietf.org by ietf.org id aa22186; 12 Mar 97 7:51 EST
Received: from fxiod04.is.chrysler.com by ietf.org id aa21968;
12 Mar 97 7:48 EST
Received: by fxiod04.is.chrysler.com; id AA09699; Wed, 12 Mar 97 07:45:53 EST
Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod04.is.chrysler.com via smap (V3.1.1)
id xma009685; Wed, 12 Mar 97 07:45:45 -0500
Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id HAA10946; Wed, 12 Mar 1997 07:30:27 -0500 (EST)
Message-Id: <3.0.1.32.19970312072522.009a9100 at dilbert.is.chrysler.com>
Reply-To: rgm3 at chrysler.com
X-Sender: rgm3 at dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 12 Mar 1997 07:25:22 -0500
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>,
Keith Moore <moore at cs.utk.edu>
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: call for a new email infrastructure
Cc: ietf at ietf.org
In-Reply-To: <Pine.SUN.3.91.970311013555.7676F-100000 at cybercash.com>
References: <199703110620.BAA08638 at ig.cs.utk.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
At 01:56 AM 3/11/97 -0500, Donald E. Eastlake 3rd wrote:
>
>You are making a lot of unwarranted assumptions about there being a poor
>user interface. You should also note that many spammers leave out .edu,
>.gov, and some other TLDs. So you are behind the poor people in .com for
>general spam volume.
Not to bring the evil eye....
I get 2-4 spams a day in a 400-500 message a day environment. I tend to
get more unsubscribe and the like than spams. But then, I don't use USENET.
As the cost of connectivity goes down, and access speeds go up, and UAs
improve, SPAM will move to a minor problem. Most SPAMs stay in my in box,
having failed my filters. Typically, 15 messages a day stay in my in box.
Thus SPAMs are easy to pitch manually. I have thought of adding a delete
filter for the text 'SPAM' in the subject, but then I would miss all of the
'lets kill SPAM messages' :) Of course this thread was carefully
subjected to avoid such filters....
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.org by ietf.org id aa22184; 12 Mar 97 7:51 EST
Received: from fxiod05.is.chrysler.com by ietf.org id aa21999;
12 Mar 97 7:48 EST
Received: by fxiod05.is.chrysler.com; id AA05817; Wed, 12 Mar 97 07:46:04 EST
Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod05.is.chrysler.com via smap (V3.1.1)
id xma005805; Wed, 12 Mar 97 07:45:45 -0500
Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id HAA10948; Wed, 12 Mar 1997 07:30:27 -0500 (EST)
Message-Id: <3.0.1.32.19970312072809.00afeb30 at dilbert.is.chrysler.com>
Reply-To: rgm3 at chrysler.com
X-Sender: rgm3 at dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 12 Mar 1997 07:28:09 -0500
To: John Harvey <johnbob at io.com>, ietf at ietf.org
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: call for a new email infrastructure
In-Reply-To: <Pine.A32.3.95.970311010201.18204A-100000 at loopback>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
At 01:28 AM 3/11/97 -0600, John Harvey wrote:
>
>Perhaps we could develop a fetch based email system. Instead of sending
>out the body of the message itself send a message id and a location from
>which to fetch it.
...
>For mailing lists (that you subscribe to,
>like ietf) the message id and location could be forwarded instead of the
>body so that it can be fetched from the originator.
Never work for large lists. This means if I post to a large list, my
server on the end of a V.34 dedicated link (htt-consult.com) would be hit a
few thousand times for the fetch.
Yet another good idea that really makes basic functionality function worst.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.org by ietf.org id aa22187; 12 Mar 97 7:51 EST
Received: from fxiod05.is.chrysler.com by ietf.org id aa21998;
12 Mar 97 7:48 EST
Received: by fxiod05.is.chrysler.com; id AA05812; Wed, 12 Mar 97 07:46:04 EST
Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod05.is.chrysler.com via smap (V3.1.1)
id xma005804; Wed, 12 Mar 97 07:45:44 -0500
Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id HAA10944; Wed, 12 Mar 1997 07:30:26 -0500 (EST)
Message-Id: <3.0.1.32.19970312071805.009b2170 at dilbert.is.chrysler.com>
Reply-To: rgm3 at chrysler.com
X-Sender: rgm3 at dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 12 Mar 1997 07:18:05 -0500
To: Keith Moore <moore at cs.utk.edu>,
"Donald E. Eastlake 3rd" <dee at cybercash.com>
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: call for a new email infrastructure
Cc: ietf at ietf.org, moore at cs.utk.edu
In-Reply-To: <199703110620.BAA08638 at ig.cs.utk.edu>
References: <Your message of "Mon, 10 Mar 1997 18:37:07 EST." <Pine.SUN.3.91.970310171505.28778G-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
At 01:20 AM 3/11/97 -0500, Keith Moore wrote:
>
>The cure is worse than the disease.
The disease is societal. If you want to participate in public discussions
and/or have a publically findable email address, you will receive spam, no
matter what the mail payment process.
I have colleagues that have private PO boxes for business only mail.
Nothing comes to them but pre-established business communications. I have
managers here that we have schooled not to post to any public descussion
area, and we do not put there addresses up in any directory.
We have more important issues to solve. Deploying authenticated mail
systems for its real value (business communications) is a critical step.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.org by ietf.org id aa22185; 12 Mar 97 7:51 EST
Received: from fxiod04.is.chrysler.com by ietf.org id aa21983;
12 Mar 97 7:48 EST
Received: by fxiod04.is.chrysler.com; id AA09695; Wed, 12 Mar 97 07:45:53 EST
Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod04.is.chrysler.com via smap (V3.1.1)
id xma009686; Wed, 12 Mar 97 07:45:46 -0500
Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id HAA10950; Wed, 12 Mar 1997 07:30:28 -0500 (EST)
Message-Id: <3.0.1.32.19970312073710.009aa150 at dilbert.is.chrysler.com>
Reply-To: rgm3 at chrysler.com
X-Sender: rgm3 at dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 12 Mar 1997 07:37:10 -0500
To: John Harvey <johnbob at io.com>,
Steen Larsen <steen.larsen at ed.nce.sita.int>
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: call for a new email infrastructure - Not needed
Cc: ietf at ietf.org
In-Reply-To: <Pine.A32.3.95.970311090035.16818A-100000 at loopback>
References: <3325566B.EA8 at ed.nce.sita.int>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
At 09:16 AM 3/11/97 -0600, John Harvey wrote:
>Yes, the mechanism exists with MIME. But there is no policy that all must
>use it.
>I'm trying to find a way that the basic mail system requires accurate
>identification of the source. Some way that a junkmail message body never
>leaves the source except to people who want it. Some way that the initial
Multipart/Signed and/or S/MIME. We have already defined how to do it and
products are starting to trickle out.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.org by ietf.org id aa26845; 12 Mar 97 9:30 EST
Received: from ietf.ietf.org by ietf.org id aa26530; 12 Mar 97 9:27 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: cat-ietf at 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-cat-kerb-chg-password-00.txt
Date: Wed, 12 Mar 1997 09:26:59 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703120927.aa26530 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 Common Authentication
Technology Working Group of the IETF.
Title : Kerberos Change Password Protocol
Author(s) : M. Horowitz
Filename : draft-ietf-cat-kerb-chg-password-00.txt
Pages : 4
Date : 03/10/1997
The Kerberos V5 protocol [RFC1510] does not describe any mechanism for
users to change their own passwords. In order to promote interoperability
between workstations, personal computers, terminal servers, routers, and
KDC's from multiple vendors, a common password changing protocol is
required.
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-cat-kerb-chg-password-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg-password-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-cat-kerb-chg-password-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: <19970310114444.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-cat-kerb-chg-password-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-kerb-chg-password-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310114444.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26853; 12 Mar 97 9:30 EST
Received: from ietf.ietf.org by ietf.org id aa26459; 12 Mar 97 9:26 EST
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-negotiation-01.txt
Date: Wed, 12 Mar 1997 09:26:48 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703120926.aa26459 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Transfer Protocol
Working Group of the IETF.
Title : Transparent Content Negotiation in HTTP
Author(s) : K. Holtman, A. Mutz
Filename : draft-ietf-http-negotiation-01.txt
Pages : 37
Date : 03/10/1997
HTTP allows web site authors to put multiple versions of the same
information under a single URL. Transparent content negotiation is a
mechanism, layered on top of HTTP, for automatically selecting the best
version when the URL is accessed. This enables the smooth deployment of
new web data formats and markup tags.
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-negotiation-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-negotiation-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-http-negotiation-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.
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: <19970310113845.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-negotiation-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-negotiation-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310113845.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26856; 12 Mar 97 9:30 EST
Received: from ietf.ietf.org by ietf.org id aa26515; 12 Mar 97 9:27 EST
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-bryant-00.txt
Date: Wed, 12 Mar 1997 09:27:05 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703120927.aa26515 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : APPN Implementer's Workshop Closed Pages Document
Author(s) : D. Bryant, P. Brittain
Filename : draft-rfced-info-bryant-00.txt
Pages : 22
Date : 03/10/1997
This document specifies
- a set of extensions to RFC 1795 designed to improve
the scalability of DLSw
- clarifications to RFC 1795 in the light of the
implementation experience to-date.
It is assumed that the reader is familiar with DLSw and RFC 1795.
No effort has been made to explain these existing protocols or
associated terminology.
This document was developed in the DLSw Related Interest Group (RIG) of the
APPN Implementers Workshop (AIW). If you would like to participate in
future DLSw discussions, please subscribe to the DLSw RIG mailing lists by
sending a mail to majordomo at raleigh.ibm.com specifying 'subscribe aiw-dlsw'
as the body of the 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-rfced-info-bryant-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-bryant-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-rfced-info-bryant-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: <19970310175002.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-bryant-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-bryant-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310175002.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26848; 12 Mar 97 9:30 EST
Received: from ietf.ietf.org by ietf.org id aa26465; 12 Mar 97 9:26 EST
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-clarify-06.txt
Date: Wed, 12 Mar 1997 09:26:54 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703120926.aa26465 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 DNS IXFR, Notification, and
Dynamic Update Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : Clarifications to the DNS Specification
Author(s) : R. Elz, R. Bush
Filename : draft-ietf-dnsind-clarify-06.txt
Pages : 14
Date : 03/10/1997
This draft considers some areas that have been identified as problems with
the specification of the Domain Name System, and proposes remedies for the
defects identified. Six separate issues are considered:
+ IP packet header address usage from multi-homed servers,
+ TTLs in sets of records with the same name, class, and type,
+ correct handling of zone cuts,
+ two minor issues concerning SOA records and their use,
+ the issue of what is an authoritative, or canonical, name,
+ and the issue of what makes a valid DNS label.
The first four of these are areas where the correct behaviour
has been somewhat unclear, we seek to rectify that. The other two
are already adequately specified, however the specifications seem
to be sometimes ignored. We seek to reinforce the existing specifications.
This version tightens the procedures to be followed when a server receives
an RRSet with varying TTLs on the RRs comprising the RRSet. This is an
attempt to limit the spread of bogus data. This paragraph will be deleted
from the final version of this document.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dnsind-clarify-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-clarify-06.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-dnsind-clarify-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.
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: <19970310131514.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnsind-clarify-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnsind-clarify-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310131514.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26990; 12 Mar 97 9:31 EST
Received: from ietf.ietf.org by ietf.org id aa26526; 12 Mar 97 9:27 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dhcp-v4 at bucknell.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-dhc-dhcp-dns-03.txt
Date: Wed, 12 Mar 1997 09:27:01 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703120927.aa26526 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Dynamic Host Configuration
Working Group of the IETF.
Title : Interaction between DHCP and DNS
Author(s) : Y. Rekhter
Filename : draft-ietf-dhc-dhcp-dns-03.txt
Pages : 7
Date : 03/10/1997
DHCP provides a powerful mechanism for IP host autoconfiguration. However,
the autoconfiguration provided by DHCP does not include updating DNS, and
specifically updating the name to address and address to name mappings
maintained by DNS.
This document specifies how DHCP clients and servers should use the
Dynamic DNS Updates mechanism to update the DNS name to address and
address to name mapping, so that the mappings for DHCP clients would be
consistent with the IP addresses that the clients acquire via DHCP.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-dhcp-dns-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-dhcp-dns-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-dhc-dhcp-dns-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.
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: <19970310141915.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-dhcp-dns-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-dhcp-dns-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310141915.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26852; 12 Mar 97 9:30 EST
Received: from ietf.ietf.org by ietf.org id aa26499; 12 Mar 97 9:27 EST
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-weider-iab-char-wrkshop-01.txt
Date: Wed, 12 Mar 1997 09:27:03 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703120927.aa26499 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The Report of the IAB Character Set Workshop held 29
February - 1 March, 1996
Author(s) : C. Weider, C. Preston, K. Simonsen, H. Alvestrand,
R. Atkinson, M. Crispin, P. Svanberg
Filename : draft-weider-iab-char-wrkshop-01.txt
Pages : 27
Date : 03/10/1997
This report details the conclusions of an IAB-sponsored invitational
workshop held 29 February - 1 March, 1996, to discuss the use of character
sets on the Internet. It motivates the need to have character set handling
in Internet protocols which transmit text, provides a conceptual framework
for specifying character sets, recommends the use of MIME tagging for
transmitted text, recommends a default character set *without* stating that
there is no need for other character sets, and makes a series of
recommendations to the IAB, IANA, and the IESG for furthering the
integration of the character set framework into text transmission
protocols.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-weider-iab-char-wrkshop-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-weider-iab-char-wrkshop-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-weider-iab-char-wrkshop-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.
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: <19970310144523.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-weider-iab-char-wrkshop-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-weider-iab-char-wrkshop-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310144523.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26842; 12 Mar 97 9:30 EST
Received: from ietf.ietf.org by ietf.org id aa26405; 12 Mar 97 9:26 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ftp-wg at hops.ag.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-ftpext-intl-ftp-01.txt
Date: Wed, 12 Mar 1997 09:26:38 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703120926.aa26405 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 Extensions to FTP Working
Group of the IETF.
Title : Internationalization of the File Transfer Protocol
Author(s) : B. Curtin
Filename : draft-ietf-ftpext-intl-ftp-01.txt
Pages : 15
Date : 03/10/1997
The File Transfer Protocol, as defined in RFC 959 [RFC959] and RFC 1123
Section 4 [RFC1123], is one of the oldest and widely used protocols on the
Internet. The protocol's primary character set, 7 bit ASCII, has served the
protocol well through the early growth years of the Internet. However, as
the Internet becomes more global, there is a need to support character sets
beyond 7 bit ASCII.
This document addresses the internationalization (I18n) of FTP, which
includes supporting the multiple character sets found throughout the
Internet community. This is achieved by extending the FTP specification
and giving recommendations for proper internationalization support.
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-ftpext-intl-ftp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ftpext-intl-ftp-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-ftpext-intl-ftp-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.
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: <19970310120930.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ftpext-intl-ftp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ftpext-intl-ftp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310120930.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26846; 12 Mar 97 9:30 EST
Received: from ietf.ietf.org by ietf.org id aa26444; 12 Mar 97 9:26 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-dnsrr-03.txt
Date: Wed, 12 Mar 1997 09:26:45 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703120926.aa26444 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 Roaming Operations Working
Group of the IETF.
Title : The Roaming Relationship (REL) Resource Record
in the DNS
Author(s) : B. Aboba
Filename : draft-ietf-roamops-dnsrr-03.txt
Pages : 13
Date : 03/10/1997
This document describes the use of the Roaming Relationship (REL) record in
the DNS for the description of roaming relationships. REL resource records
may be used for determining the existence of a roaming relationship path
between the local ISP and the user's home domain, as well as the location
of an appropriate accounting agent. However, unless the roaming
relationship path is authenticated by some method (such as via tokens or
certificates returned by the home authentication server), hierarchical
authentication routing must be used in order to validate the path.
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-roamops-dnsrr-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-dnsrr-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-roamops-dnsrr-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.
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: <19970310103820.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-dnsrr-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-dnsrr-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310103820.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26854; 12 Mar 97 9:30 EST
Received: from ietf.ietf.org by ietf.org id aa26428; 12 Mar 97 9:26 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-radius at livingston.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-radius-tunnel-imp-01.txt
Date: Wed, 12 Mar 1997 09:26:42 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703120926.aa26428 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 Remote Authentication
Dial-In User Service Working Group of the IETF.
Title : Implementation of Mandatory Tunneling via RADIUS
Author(s) : B. Aboba, G. Zorn
Filename : draft-ietf-radius-tunnel-imp-01.txt
Pages : 17
Date : 03/10/1997
This document discusses implementation issues arising in the provisioning
of mandatory tunneling in dial-up networks using the PPTP and L2TP
protocols. This provisioning may be accomplished via the integration of
RADIUS and tunneling protocols.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-radius-tunnel-imp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-radius-tunnel-imp-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
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-radius-tunnel-imp-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.
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: <19970310103222.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-radius-tunnel-imp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-radius-tunnel-imp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310103222.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05089; 12 Mar 97 11:50 EST
Received: from box.nl by ietf.org id aa04695; 12 Mar 97 11:41 EST
Received: from cs-gj3-a8.hro.nl (cs-gj3-a8.hro.nl [145.24.129.140]) by box.nl (8.7.5/8.6.9) with SMTP id RAA19886 for <ietf at ietf.org>; Wed, 12 Mar 1997 17:38:52 +0100
Date: Wed, 12 Mar 1997 17:38:52 +0100
Message-Id: <199703121638.RAA19886 at box.nl>
X-Sender: unit at box.nl
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: michael_roetto <mike at box.nl>
Subject: My Apologies
Source-Info: From (or Sender) name not authenticated.
To IETF list subscribers,
Please accept my sincere apologies for sending my unsubscribe message to the
wrong address; just a typo when I was in a hurry...
Now I'll leave everyone to discussion more important ideas, like the Memphis
hotel arrangements...
sincerely,
Michael Roetto
::::::::::::::::::::::::::::::::::::::::::
: Internet Design Unit :
: http://www.box.nl/~unit/idu :
: :
: Personal Page: :
: http://www.box.nl/~unit/mike :
::::::::::::::::::::::::::::::::::::::::::
Received: from ietf.org by ietf.org id aa05330; 12 Mar 97 11:51 EST
Received: from box.nl by ietf.org id aa05149; 12 Mar 97 11:50 EST
Received: from cs-gj3-a8.hro.nl (cs-gj3-a8.hro.nl [145.24.129.140]) by box.nl (8.7.5/8.6.9) with SMTP id RAA19995 for <ietf at ietf.org>; Wed, 12 Mar 1997 17:48:06 +0100
Date: Wed, 12 Mar 1997 17:48:06 +0100
Message-Id: <199703121648.RAA19995 at box.nl>
X-Sender: unit at box.nl (Unverified)
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: michael_roetto <mike at box.nl>
Subject: appending my apologies
Source-Info: From (or Sender) name not authenticated.
Dear Members,
I just spend a good 15 minutes deleting about 50 different messages
'correcting' my oversight in sending my unsubscribe message to the wrong
address.
Having been on this list for the last six months or so, I have received many
remove messages. Were these people 'mail-bombed' like myself? Or am I just
being made an example of?
I think the response I received for a simple mistake is really out of line.
-michael_roetto
Received: from ietf.org by ietf.org id aa06916; 12 Mar 97 12:16 EST
Received: from jekyll.piermont.com by ietf.org id aa06855; 12 Mar 97 12:15 EST
Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.5/8.6.12) with SMTP id MAA03618; Wed, 12 Mar 1997 12:11:30 -0500 (EST)
Message-Id: <199703121711.MAA03618 at jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol
To: michael_roetto <mike at box.nl>
cc: ietf at ietf.org
Subject: Re: appending my apologies
In-reply-to: Your message of "Wed, 12 Mar 1997 17:48:06 +0100."
<199703121648.RAA19995 at box.nl>
Reply-To: perry at piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 12 Mar 1997 12:11:25 -0500
Sender:ietf-request at ietf.org
From: "Perry E. Metzger" <perry at piermont.com>
Source-Info: From (or Sender) name not authenticated.
michael_roetto writes:
> Having been on this list for the last six months or so, I have received many
> remove messages. Were these people 'mail-bombed' like myself? Or am I just
> being made an example of?
1) I, for one, almost always complain about such things, so no, don't
feel that you are special.
2) Being told that your behavior is unacceptable by fifty different
people isn't being "mail bombed". Mail bombing would mean one
person sending you a message fifty times.
> I think the response I received for a simple mistake is really out of line.
It isn't a simple mistake. Its a very annoying mistake that is made
way too often by people who should know better. It is on the order of
public urination -- something that causes no real harm but which is
thought of as being offensive and out of societal norms.
Received: from ietf.org by ietf.org id aa06992; 12 Mar 97 12:16 EST
Received: from noc.msc.edu by ietf.org id aa06953; 12 Mar 97 12:16 EST
Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324))
id AA19773; Wed, 12 Mar 97 11:13:19 -0600
Sender:ietf-request at ietf.org
From: Tim Salo <salo at msc.edu>
Received: (salo at localhost) by uh.msc.edu (8.7.1/8.6.6) id LAA01832; Wed, 12 Mar 1997 11:13:23 -0600 (CST)
Date: Wed, 12 Mar 1997 11:13:23 -0600 (CST)
Message-Id: <199703121713.LAA01832 at uh.msc.edu>
To: ietf at ietf.org, mike at box.nl
Subject: Re: appending my apologies
Source-Info: From (or Sender) name not authenticated.
> I just spend a good 15 minutes deleting about 50 different messages
> 'correcting' my oversight in sending my unsubscribe message to the wrong
> address.
I used to work for a VP of software development who, when he was having
a particularly bad day, would call in some poor salesman [1] and beat him
up (verbally). I think his reasoning was that if he beat up his
subordinates, then his already late deliveries would be even later.
On the other hand, the salesman needed him more than he needed the salesman,
and so made a good target on which to vent.
I always thought that the VP's evil twins reside on many of the mail lists
I read, and when they have a bad day, they go hunting for some unfortunate
soul who sends an "unsubscribe" message to the list. These poor souls make
ideal targets since they want to get off of the list anyway, so they
probably won't stick around to try to explain that there are at least
nineteen "standard" ways of getting removed from mail lists.
Unfortunately, these evil twins, at least when they are having a particularly
bad day, often feel compelled to sent their mail to whole list. As a result,
I have to see the "unsubscribe" message followed by a sometimes long
discussion about "unsubscribe" messages.
And finally, I know that somewhere out there, yet another evil twin of
my ex-VP will be having a bad day, and will send me mail about how I
was wasting his or her time. And, unfortunately, she, he, or it [shit] will
probably copy the whole list, so you too, will know that she/he/it
is having a bad day. Which may only make your day worse. And the
cycle continues.
-tjs
[1] Lest I be skewered for being gender specific, it should be noted that
the VP was a rather traditional guy, and only seemed inclined to beat up on
male salespersons. I don't think the female salespersons liked dealing with
him. Actually, I don't think that salespersons of any gender liked dealing
with him.
Received: from ietf.org by ietf.org id aa13386; 12 Mar 97 14:39 EST
Received: from [202.41.99.2] by ietf.org id aa13187; 12 Mar 97 14:33 EST
Received: from iisc.ernet.in by milan.doe.ernet.in (4.1/SMI-4.1)
id AA13667; Thu, 13 Mar 97 00:40:57+050
Received: from csa.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1)
id AAA25420; Thu, 13 Mar 1997 00:59:59 +0530
Received: from Kohinoor.csa.iisc.ernet.in (kohinoor.csa.iisc.ernet.in [144.16.67.10]) by csa.iisc.ernet.in (8.6.11/8.6.9) with SMTP id BAA24352 for <ietf at ietf.org>; Thu, 13 Mar 1997 01:36:04 +0530
Received: by Kohinoor.csa.iisc.ernet.in (5.x/SMI-SVR4)
id AA20989; Thu, 13 Mar 1997 00:58:27 +0530
Message-Id: <9703121928.AA20989 at Kohinoor.csa.iisc.ernet.in>
Subject: ietf: mailing lists on ip traffic measurements ?
To: ietf at ietf.org
Date: Thu, 13 Mar 1997 00:58:26 +0530 (IST)
Cc: Dinesh <dinesh at kohinoor.csa.iisc.ernet.in>
Sender:ietf-request at ietf.org
From: Dinesh <dinesh at csa.iisc.ernet.in>
Reply-To: dinesh at csa.iisc.ernet.in
Return-Receipt-To: dinesh at csa.iisc.ernet.in
Request-Delivery-Notification: TRUE
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.
sirs/madams,
A. is there a list of the ietf which discusses issues on
a. reducing bandwidth consumption
b. internet traffic measurement and studies
if not, are there any other mailing lists ?
the ippm list ( ip perforance and measurement ) is very quiet.
B. is there a moderated list of the ietf ?
in all probability, the questions are very basic.
if so, please do send me the answers by email to
dinesh at csa.iisc.ernet.in
sorry to disturb the current discussion.
-dt
dinesh thirumurthy
research scholar, computer science and automation
indian institute of science, bangalore, india
Received: from cnri by ietf.org id aa14861; 12 Mar 97 15:03 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18701;
12 Mar 97 15:03 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA00677 at pad-thai.cam.ov.com>; Wed, 12 Mar 1997 17:42:46 GMT
To: marc at cygnus.com
Cc: cat-ietf at mit.edu
Subject: kerb-chg-password
References: <9703120927.aa26530 at ietf.org>
Mime-Version: 1.0 (generated by tm-edit 7.103)
Content-Type: text/plain; charset=US-ASCII
From: Johan Danielsson <joda at pdc.kth.se>
Date: 12 Mar 1997 18:42:13 +0100
In-Reply-To: Internet-Drafts at ietf.org's message of Wed, 12 Mar 1997 09:26:59 -0500
Message-Id: <xofybbtuhvu.fsf at blubb.pdc.kth.se>
Lines: 15
X-Mailer: Gnus v5.4.24/Emacs 19.34
Precedence: bulk
Hello.
I appreciate the effort to specify a protocol for password changing. A
few questions arise though.
What is the reason behind specifying UDP as the primary protocol?
Using "unsafe" protocols will, as mentioned in the draft, require a
lot of extra sanity checks.
Also, what about the "message length" and "AP_REQ length" fields? As I
see it, these fields limits the whole message to 64k (not that I think
that's a major problem), and adds unnecessary information (since the
lengths of the AP-REQ and KRB-PRIV are implied by the ASN.1 strings).
/Johan
Received: from ietf.org by ietf.org id aa15989; 12 Mar 97 15:31 EST
Received: from skyweyr.com by ietf.org id aa15918; 12 Mar 97 15:29 EST
Received: from [128.2.98.8] (SEUSS.RES.CMU.EDU [128.2.98.8])
by skyweyr.com (8.8.4/8.8.4) with ESMTP
id MAA14856 for <ietf at ietf.org>; Wed, 12 Mar 1997 12:26:13 -0800 (PST)
X-Sender: josh at grinch.res.cmu.edu
Message-Id: <v0302090faf4cc0de605b at [128.2.98.8]>
In-Reply-To: <3.0.1.32.19970311201302.00e88668 at mailhost.oc.com>
References: <199703112315.RAA23372 at uh.msc.edu>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"
X-URL: http://thelorax.skyweyr.com/josh.html
X-Planation: My mountain is waiting...
Date: Wed, 12 Mar 1997 15:25:13 -0500
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: "Joshua D. Baer" <josh at skyweyr.com>
Subject: Re: remove
Source-Info: From (or Sender) name not authenticated.
At 9:13 PM -0500 3/11/97, Cleve Graves wrote:
<excerpt>
So why don't we put a "remove/unsubscribe" filter in, monitor what it
takes out and doesn't take out, correct problems, and make out
listserver a model for what to expect a listserver to do now that we
have Internet toaster and "toaster USERS". And let us not forget that
USER always has been and always will be a four letter word.... Thank
god, for what would we be doing without them?
</excerpt>
This is the approach I took with the latest release of ListSTAR for the
Macintosh. I've NEVER seen someone post a message to the list with
subject "remove" who really wanted to post something. So we trap for
it, and unsubscribe the person. Our server has it's own simple syntax,
but we also accept all other listserver syntaxes, because we know
people are going to send them anyway. Very few messages like this ever
get posted to the list. Other list managers have done this to a lesser
degree, such as LetterRip and Lyris.
Again, if you'r interested in helping stop this, check out the List
Headers proposal.
<<URL:mailto:list-header at arpp.carleton.ca?subject=subscribe>
~Josh
-- ----------------------------------
Joshua D. Baer
SkyList Mailing List Hosting Service
http://cgi.skyweyr.com/Guest.Login
Received: from cnri by ietf.org id aa20711; 12 Mar 97 18:05 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23094;
12 Mar 97 18:05 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <VAA11120 at pad-thai.cam.ov.com>; Wed, 12 Mar 1997 21:34:16 GMT
Message-Id: <3327210C.3FBA at trsvr.tr.unisys.com>
Date: Wed, 12 Mar 1997 16:33:00 -0500
From: Bill Buffam <bjb at trsvr.tr.unisys.com>
Reply-To: bjb at trsvr.tr.unisys.com
Organization: Unisys
X-Mailer: Mozilla 3.0Gold (WinNT; I)
Mime-Version: 1.0
To: cat-ietf at mit.edu, CryptoAPI at listserv.msn.com, ssl-talk at netscape.com
Subject: GSS-API and SSL - their coexistence, and related issues
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Judging by the traffic level, it seems to me that there's a lot of
apathy on the question of the merits and feasibility of putting GSS-API
over SSL. Which leads me to think that perhaps this is the wrong
question. I want to try to summarize what I think are the requirements,
and what the options and issues are.
(in what follows, I'm using "mechanism" in its jargon sense, to indicate
a GSS mechanism (for example, Kerberos))
Requirements
1) Mechanism-independent API for applications and middleware to use.
2) Transport-independent mechanisms
3) CryptoAlgorithm-independent mechanisms.
Possible Options
1) GSS-API as the mechanism-independent API.
Issues:
(a) Application writers seem not to like GSS-API. It seems very
cumbersome to program.
(b) SSL wasn't designed to fit under GSS-API, and force fitting it seems
to require much effort and some compromise.
(c) Popular support for GSS-API seems weak. It's now the native
interface to Kerberos, but the only other mechanism so far using it is
Entrust's SPKM (an X.509-based public key mechanism). No other
developer, to the best of my knowledge, has embraced SPKM. (Can anyone
from Entrust comment on the uptake of GSS-API in the Entrust user base?)
(d) Microsoft has publicly stated a commitment to SSPI (Windows-style
GSS-API) as its native interface to Kerberos and SSL, yet has been
silent since the beginning of this discussion questioning the
feasibility of GSS/SSL coexistence. (Hello Microsoft. Can you comment?)
2) Winsock (or similar) as the mechanism-independent API.
Issues:
(a) A Winsock-style interface may be ideal for applications that want a
minimum of aggravation in invoking security functions, but a management
API will be needed to configure behavior that the application writer
likely doesn't care about (or doesn't know enough to decide, or should
by policy be decided at a more global level) (e.g. ciphersuites)
(b) We just moved the responsibility for organizing the transport
independence. With GSS-API, the caller is responsible for managing the
transport. With Winsock (or similar) we're making the SSL layer
responsible for the transport. This seems to be an advantage. Firstly,
the application is freed from a lot a tedious state maintenance, and
sees a much simpler interface. Secondly, in systems that only care about
TCP/IP, that's the only transport we need to implement. Thirdly, in
systems that do need to deal with other transports, we make the
selection and handling of that transport the responsibility of the
system (not the application) and control its selection through the
(putative) management interface.
(c) We can apparently embrace Kerberos migration within the SSL
mechanism, as defined in
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-kerb-cipher-suites-00.txt
This implies that SSL (or TLS or whatever it becomes) becomes the
unifying framework within which all future session-oriented security
mechanisms will live. It appears to set the stage for GSS-API and
SSL/TLS to compete for the role of unifying orchestrator of
session-oriented security. The very existence of this draft seems to me
to be a tacit admission that current SSL techniques are more
developer-friendly than GSS-API. Perhaps the authors could comment.
3) No standard API. Each mechanism does its own thing.
Issues:
(a) Ugh!
Summary - Issues - Musings
Option 2 looks, in some respects, very attractive. Yet it seems to give
SSL/TLS the crown jewels as the central nucleus of session-oriented
security. Is that what we want?
As a security middleware developer, I want to apply my efforts to the
APIs that application developers want to see and will find most
effective to use. So to all the application developers out there I ask,
What are your preferences on these issues? Do you have Kerberos
migration and expansion (to public key) issues? Or are you jumping
straight into SSL and embedding it in your applications? Is each
application going to have its own embedded SSL? What API do you want to
see? Do you care about transports other than TCP/IP?
If you're subscribed to these lists, and you don't care about these
issues, I'd be really interested to know *why* you don't care.
And if you got this far, thanks.
--
Bill Buffam
Unisys, Malvern PA
bjb at trsvr.tr.unisys.com
Received: from cnri by ietf.org id aa21668; 12 Mar 97 19:06 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24220;
12 Mar 97 19:06 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <WAA12540 at pad-thai.cam.ov.com>; Wed, 12 Mar 1997 22:08:50 GMT
Message-Id: <61CDD2C9A961CF11B6A000805FD40AA9030F91E3 at RED-84-MSG.dns.microsoft.com>
From: Glen Zorn <glennz at microsoft.com>
To: bjb at trsvr.tr.unisys.com, cat-ietf at mit.edu, CryptoAPI at listserv.msn.com,
ssl-talk at netscape.com
Subject: RE: SSL underneath GSS-API/SSPI (again)
Date: Wed, 12 Mar 1997 13:59:42 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Precedence: bulk
Bill Buffam [bjb at trsvr.tr.unisys.com] writes:
There has been some interesting discussion over the last few
days, on
both ssl-talk and cat-ietf, on the subject of putting SSL
underneath
GSS-API. Opinions were all over the map: yes, you could do
that, but
why would you want to? - we tried it, but we had to make a
lot of
assumptions in SSL and it wasn't useful - we really want to
decouple
our applications from the underlying mechanism.
In Microsoft's Security Design review (Sept 96), they presented
an
architectural picture with SSL sitting alongside Kerberos (and
NTLM and
other mechanisms) underneath GSS-API (or rather, Microsoft's
SSPI
equivalent).
Insofar as I know, SSPI and GGS-API are _not_ equivalent,
although SSPI syntactically resembles older versions of GSS. SSPI is a
"pure" API - it has no wire-protocol assumptions. GSS is _not_ a pure
API, in that the GSS does not merely offer access to underlying
protocols in a uniform manner, but actually modifies the protocols
themselves. To illustrate, a V5 Kerberos client that is RFC
1510-compliant will not be able to interoperate with a server written
using the GSS-API Kerb V5 mechanism.
Yet Eric Murray tells us he's already tried that and it was
essentially a failure.
I'd be very interested in hearing Microsoft comment on Eric's
experience, and for them to tell us how things are going with
the
SSL-under-SSPI development.
Meanwhile, my own view is that it makes little sense to impose
mechanism-specific APIs on applications. There is a lot of
benefit to
having an API that runs over multiple mechanisms. (And yes, I'm
aware of
the idealized view that applications should call DCOM or RPC,
and the
mechanism interface is below that - but there are many
situations
(probably mostly legacy c/s interactions) where that model won't
work.)
It seems to me that there are, in general, two interfaces needed
for the
average GSS mechanism - one for applications, one for
management. The
management API is used to set policy, and therefore must be
mechanism-specific (for example, such policy issues would be, in
SSL,
cipher-suite/QoS mappings, key exchange mechanism, and any other
mechanism-specific aspect of behavior that most applications
would not
want to have to bother with).
I'm somewhat surprised by how little traffic this topic has
generated.
To me, it looks like a real disaster if GSS apps currently using
Kerberos have to be rewritten to some ad hoc interface on top of
SSL,
(or whatever the next mechanism is) rather than have the new
mechanisms
sit underneath the old interface.
BTW, if anyone wants a summary of messages on this thread to
date, I
collected most of them at
http://www.chesco.com/~buffam/Security/Articles/gss-ssl.txt
--
Bill Buffam
Unisys, Malvern PA
bjb at trsvr.tr.unisys.com
Received: from cnri by ietf.org id aa21704; 12 Mar 97 19:08 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24242;
12 Mar 97 19:08 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <VAA11400 at pad-thai.cam.ov.com>; Wed, 12 Mar 1997 21:42:46 GMT
Message-Id: <A1A89B76BC87CF11925C00805FD4224C01E8F2C9 at RED-102-MSG.dns.microsoft.com>
From: "Richard B. Ward" <richardw at microsoft.com>
To: "'bjb at trsvr.tr.unisys.com'" <bjb at trsvr.tr.unisys.com>
Cc: cat-ietf at mit.edu, CryptoAPI at listserv.msn.com
Subject: RE: SSL underneath GSS-API/SSPI (again) [long]
Date: Wed, 12 Mar 1997 13:42:16 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Precedence: bulk
Well, with an invitation like that, we have to chime in.
The short answer is, yes, Microsoft's SSL implementation is a security
provider (analogous to mechanism) under the SSPI API boundary. Like all
short answers, there are a few caveats associated with it.
1) SSL the protocol does not map cleanly onto the GSS model of
authentication. GSS assumes that the calling application has reserved
room in its protocol and is at least nominally aware of security, if
only to the point of transmitting opaque security tokens. SSL the
protocol was designed to secure applications that are essentially
security intolerant, namely HTTP servers, by providing a virtual socket
out of which the application would obtain all of its data.
2) SSL the pk-based-authentication-scheme (*not* the wire protocol)
makes a great authentication protocol, mostly, and if you treat the
header/trailer stuff as the mechanism's token, you can get along pretty
well.
3) SSL(3), and presumably TLS, as well, has some interesting
semantics regarding client authentication which more or less make sense
in the web environment but again, do not map cleanly to GSS. The best
example is client authentication. Under SSL3, client authentication
takes place when the server demands it, arbitrarily somewhere in the
middle of an existing context. This makes sense from the web server
point of view (when someone clicks this link, make them authenticate
themselves), but from the GSS point of view, it is awkward (mutual
authentication up front?).
Now the CAT group is wondering, how are we fitting this under the SSPI
layer, since that is directly analogous to the GSS API. For those of
you not interested in GSS v. SSPI difference, you may want to skip
ahead.
We've always said that the SSPI layer is semantically equivalent to the
GSS-API, but there are differences. Well, those differences come into
play here.
1) Security providers under SSPI understand three different "modes"
of being called, namely Connection, Datagram, and Stream. Connection is
the most similar to GSS, where the application has reserved space for
authentication tokens and MICs. Datagram was introduced to support
DCE-style RPC. There, the client initializes a security context, then
immediately sends the first packet to the server (optionally with MIC,
etc, according to the RPC binding options). The server then sends back
a message demanding authentication, to which the client replies with the
token from initialize security context. Stream is the most complicated,
and is used when the security provider is responsible for all the
message blocking. The SSL security provider parses its own data out of
the stream that the HTTP server passes it, and returns pointers to the
application portion (or distinguished errors indicating not enough data,
too much, etc.).
2) The message APIs (get_mic, verify_mic, etc.) can return a
distinguished error indicating that the application needs to call
init_sec_context again, because the server has demanded a REDO or
RENEGOTIATE.
3) Stream mode is accomplished by associating a type field with
each buffer, and allowing a list of buffers to be sent in to all the
interesting calls. Having a list of buffers also allows us to get
parsing information back out of the security provider, such as extra
data that the application needs to buffer, etc.
4) Current applications using the Microsoft SSL implementation
(Internet Explorer, IIS) are aware of SSL's requirements for streamed
connections, and know how to adjust mechanism specific features, such as
QoS and public key credentials. For the next release of NT, we are
working on improving the mechanism to not only have better defaults, but
make those defaults configurable through an external mechanism.
So, what does this boil down to? Pure, wire-compatible SSL will most
likely not be available under the GSS, due to the streaming nature of
SSL and the message nature of GSS. Taking the SSL authentication scheme
and making a message, rather than stream, based security mechanism is
entirely possible. If there is interest, we can post how we've done it.
-Rich
-----Original Message-----
From: Bill Buffam [SMTP:bjb at trsvr.tr.unisys.com]
Sent: Tuesday, March 11, 1997 1:33 PM
To: cat-ietf at MIT.EDU; CryptoAPI at LISTSERV.MSN.COM;
ssl-talk at netscape.com
Subject: SSL underneath GSS-API/SSPI (again)
There has been some interesting discussion over the last few
days, on
both ssl-talk and cat-ietf, on the subject of putting SSL
underneath
GSS-API. Opinions were all over the map: yes, you could do
that, but
why would you want to? - we tried it, but we had to make a
lot of
assumptions in SSL and it wasn't useful - we really want to
decouple
our applications from the underlying mechanism.
In Microsoft's Security Design review (Sept 96), they presented
an
architectural picture with SSL sitting alongside Kerberos (and
NTLM and
other mechanisms) underneath GSS-API (or rather, Microsoft's
SSPI
equivalent). Yet Eric Murray tells us he's already tried that
and it was
essentially a failure.
I'd be very interested in hearing Microsoft comment on Eric's
experience, and for them to tell us how things are going with
the
SSL-under-SSPI development.
Meanwhile, my own view is that it makes little sense to impose
mechanism-specific APIs on applications. There is a lot of
benefit to
having an API that runs over multiple mechanisms. (And yes, I'm
aware of
the idealized view that applications should call DCOM or RPC,
and the
mechanism interface is below that - but there are many
situations
(probably mostly legacy c/s interactions) where that model won't
work.)
It seems to me that there are, in general, two interfaces needed
for the
average GSS mechanism - one for applications, one for
management. The
management API is used to set policy, and therefore must be
mechanism-specific (for example, such policy issues would be, in
SSL,
cipher-suite/QoS mappings, key exchange mechanism, and any other
mechanism-specific aspect of behavior that most applications
would not
want to have to bother with).
I'm somewhat surprised by how little traffic this topic has
generated.
To me, it looks like a real disaster if GSS apps currently using
Kerberos have to be rewritten to some ad hoc interface on top of
SSL,
(or whatever the next mechanism is) rather than have the new
mechanisms
sit underneath the old interface.
BTW, if anyone wants a summary of messages on this thread to
date, I
collected most of them at
http://www.chesco.com/~buffam/Security/Articles/gss-ssl.txt
--
Bill Buffam
Unisys, Malvern PA
bjb at trsvr.tr.unisys.com
Received: from ietf.org by ietf.org id aa22835; 12 Mar 97 20:06 EST
Received: from servo.qualcomm.com by ietf.org id aa22374; 12 Mar 97 19:55 EST
Received: (from karn at localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id QAA17929; Wed, 12 Mar 1997 16:49:04 -0800 (PST)
Date: Wed, 12 Mar 1997 16:49:04 -0800 (PST)
Sender:ietf-request at ietf.org
From: Phil Karn <karn at qualcomm.com>
Message-Id: <199703130049.QAA17929 at servo.qualcomm.com>
To: MRC at panda.com
CC: ietf at ietf.org
In-reply-to: <MailManager.858021782.366.mrc at Ikkoku-Kan.Panda.COM> (message from Mark Crispin on Mon, 10 Mar 1997 11:23:02 -0800 (PST))
Subject: Re: call for a new email infrastructure
Source-Info: From (or Sender) name not authenticated.
Any sender-oriented anti-spam mechanism (sender pays, legal sanctions,
etc) will never work. In particular, legal sanctions would have the
same fundamental Constitutional and practical problems as the infamous
Communications Decency Act. (It amazes me just how many vociferous
opponents of the CDA can so easily call for laws against spamming.)
The only place where there's any hope of stopping *any* unwanted or
offensive Internet content, whether it be "indecency" or spam, is at
the receiver. I hold this truth to be self-evident.
The ideal anti-spam system would require all incoming email to be
signed (e.g., with PGP). Unsigned messages would automatically
bounce. An individual receiver could blacklist anyone who sends
unwanted material, and the signature mechanism would make this hard to
evade. In effect, this is a "reputation system" as it has long been
discussed by the Cypherpunks.
But the vast majority of email is not yet signed, and there are many
people without PGP from whom I would still like to receive mail. So
this calls for a more heuristic approach.
I have noticed that almost all of the spam I get is immediately
preceded or followed by a bounce message from a system I haven't used
in over 5 years. At first I thought this old system was forwarding the
spam and sending me a separate forwarding notification. Not so. I get
these pairs of messages because both my old and new email addresses
are on the spammers' mailing lists. Obviously they are after sheer
quantity, not quality; they can't possibly afford to verify that every
address on their list works before they use it.
This suggests an effective countermeasure. Deliberately "salt" the
spammers' lists. Create a bogus email address and use it to post items
to obscure Usenet groups that are unlikely to be answered. Register
it with any web sites known to cull spam lists in this way. Register
it with the online email directories. Use a fictional real name so
it's unlikely to be used by anyone who is legitimately trying to
contact you.
Now when the spammers build their lists and start spraying you with
spam, you have your mail agent and/or server look for any messages
common to your "salt" and regular email accounts and automatically
delete them from the latter. If you keep your salt account's identity
a secret, it will be nearly impossible for the spammers to avoid. And
as long as their list remains salted, they'll be unable to send you
spam.
This could be done either on an individual basis or by a subscription
service that would conduct salting efforts and make lists of spam
(either the actual texts or their MD5 hashes) available to a
subscriber's mail agent or server over the net.
The basic idea here is not at all new; essentially the same thing has
been done for years to protect proprietary mailing lists against
unauthorized use.
The only countermeasure I can think of is for the spammers to make
each of their spam messages unique somehow, and I'm not sure how to
deal with this. Any suggestions would be welcome.
Phil
Received: from cnri by ietf.org id aa22939; 12 Mar 97 20:10 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa25450;
12 Mar 97 20:10 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <XAA15963 at pad-thai.cam.ov.com>; Wed, 12 Mar 1997 23:34:05 GMT
Message-Id: <33273CE2.36D1 at dascom.com>
Date: Wed, 12 Mar 1997 15:31:46 -0800
From: John Nunneley <johnn at dascom.com>
Reply-To: johnn at dascom.com
Organization: Dascom
X-Mailer: Mozilla 3.0Gold (Win95; I)
Mime-Version: 1.0
To: bjb at trsvr.tr.unisys.com
Cc: cat-ietf at mit.edu, ssl-talk at netscape.com
Subject: Re: GSS-API and SSL - their coexistence, and related issues
References: <3327210C.3FBA at trsvr.tr.unisys.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Yes. Let's get over the specifics of the original question.
I did some more poking around on the MS site and apparently they
understand the merits of this issue quite well. The SSPI sure looks a
lot like GSSAPI on the surface, but apparently and according to some,
doesn't impose any implementation or protocol on the mechanism as some
have asserted that GSSAPI does. In fact, the lovely slides I saw show
MS fully embracing Kerberos as the replacement for NTLM authentication
and simultaneously/seamlessly supporting SSL and a smorgasborg of crypto
routines. This is what I want to write my app to. Unfortunately, I
doubt I will ever have such a thing that runs on the (other) platforms I
care about :-{
I would assert that:
Applications should not embed security policy or mechanisms. Rather
policy should be set and mechanisms selected by the administrators of
the site/system/domain that meet there needs.
Is there at least general agreement on this point? If so, the need for
such an API should be apparent. Bill Buffman made some very excellent
points. We are in a situation where none of the solutions meet all
three of the requirements. Plus, I'd add a fourth which is Platform
independence.
Is it possible to "fix" GSSAPI. Or has MS already done this for us ;)
--
------------------------------------------------------------------------
John Nunneley Phone: +1 408 457 4510
DASCOM Inc. Fax: +1 408 457 0710
1509 Seabright Avenue Email: johnn at dascom.com
Santa Cruz CA 95062 WWW: http://www.dascom.com/
------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa23262; 12 Mar 97 20:17 EST
Received: from zephyr.isi.edu by ietf.org id aa23066; 12 Mar 97 20:15 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA01740>; Wed, 12 Mar 1997 17:13:10 -0800
Message-Id: <199703130113.AA01740 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2110 on MHTML
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 12 Mar 97 17:13:10 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2110
Title: MIME E-mail Encapsulation of Aggregate
Documents, such as HTML (MHTML)
Author: J. Palme, A. Hopmann
Date: March 1997
Mailbox: jpalme at dsv.su.se, alexhop at microsoft.com
Pages: 19
Characters: 41961
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2110.txt
Although HTML [RFC 1866] was designed within the context of MIME, more
than the specification of HTML as defined in RFC 1866 is needed for
two electronic mail user agents to be able to interoperate using HTML
as a document format. This document describes a set of guidelines that
will allow conforming mail user agents to be able to send, deliver and
display these objects, such as HTML objects, that can contain links
represented by URIs. In order to be able to handle inter-linked
objects, the document uses the MIME type multipart/related and
specifies the MIME content-headers "Content-Location" and
"Content-Base". This document is a product of the MIME Encapsulation
of Aggregate HTML Documents Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--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: <970312170618.RFC at ISI.EDU>
SEND /rfc/rfc2110.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2110.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970312170618.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23586; 12 Mar 97 20:22 EST
Received: from zephyr.isi.edu by ietf.org id aa23550; 12 Mar 97 20:21 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA02029>; Wed, 12 Mar 1997 17:19:06 -0800
Message-Id: <199703130119.AA02029 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2111 on CID and MID URL
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 12 Mar 97 17:19:05 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2111
Title: Content-ID and Message-ID Uniform Resource
Locators
Author: E. Levinson
Date: March 1997
Mailbox: XIson at cnj.digex.com
Pages: 5
Characters: 9113
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2111.txt
The Uniform Resource Locator (URL) schemes, "cid:"; and "mid:"; allow
references to messages and the body parts of messages. For example,
within a single multipart message, one HTML body part might include
embedded references to other parts of the same message. This document
is a product of the MIME Encapsulation of Aggregate HTML Documents
Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--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: <970312171338.RFC at ISI.EDU>
SEND /rfc/rfc2111.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2111.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970312171338.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24024; 12 Mar 97 20:28 EST
Received: from zephyr.isi.edu by ietf.org id aa23964; 12 Mar 97 20:28 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA02439>; Wed, 12 Mar 1997 17:25:26 -0800
Message-Id: <199703130125.AA02439 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2112 on MIME Multipart/Related Content-type
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 12 Mar 97 17:25:26 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2112
Title: The MIME Multipart/Related Content-type
Author: E. Levinson
Date: March 1997
Mailbox: XIson at cnj.digex.com
Pages: 9
Characters: 17052
Updates/Obsoletes: 1872
URL: ftp://ds.internic.net/rfc/rfc2112.txt
The Multipart/Related content-type provides a common mechanism for
representing objects that are aggregates of related MIME body parts.
This document defines the Multipart/Related content-type and provides
examples of its use. This document is a product of the MIME
Encapsulation of Aggregate HTML Documents Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--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: <970312171942.RFC at ISI.EDU>
SEND /rfc/rfc2112.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2112.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970312171942.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24710; 12 Mar 97 20:42 EST
Received: from egoshin.genesyslab.com by ietf.org id aa24649;
12 Mar 97 20:41 EST
Received: (from egoshin at localhost) by egoshin.genesyslab.com (8.8.5/8.6.9) id RAA16734; Wed, 12 Mar 1997 17:39:22 -0800
Date: Wed, 12 Mar 1997 17:39:22 -0800
Sender:ietf-request at ietf.org
From: Leonid Yegoshin <egoshin at genesyslab.com>
Message-Id: <199703130139.RAA16734 at egoshin.genesyslab.com>
To: karn at qualcomm.com, MRC at panda.com
Subject: Re: call for a new email infrastructure
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
>From: Phil Karn <karn at qualcomm.com>
>
>The ideal anti-spam system would require all incoming email to be
>signed (e.g., with PGP). Unsigned messages would automatically
>bounce. An individual receiver could blacklist anyone who sends
>unwanted material, and the signature mechanism would make this hard to
>evade. In effect, this is a "reputation system" as it has long been
>discussed by the Cypherpunks.
>
As I understand this approach can give us the only two ways -
- accept all E-mails (as now) or accept the only "friendly" signed
E-mails. Please, don't forget that spammer can change his E-sign
as his address.
OK, it may be useful for business manager who want exchange
E-mail the only with partners, but certainly not for me and many others.
But we also suffer from spam !
I don't know any Internet entity which can't be changed fast
except IP [or net] address/domain name. The first requeries change
provider and second - InterNIC action ;-)
- Leonid Yegoshin, LY22
Received: from cnri by ietf.org id aa25880; 12 Mar 97 21:05 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa26363;
12 Mar 97 21:05 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <AAA18464 at pad-thai.cam.ov.com>; Thu, 13 Mar 1997 00:41:15 GMT
To: Johan Danielsson <joda at pdc.kth.se>
Cc: cat-ietf at mit.edu
Subject: Re: kerb-chg-password
References: <9703120927.aa26530 at ietf.org> <xofybbtuhvu.fsf at blubb.pdc.kth.se>
From: Marc Horowitz <marc at cygnus.com>
Date: 12 Mar 1997 19:40:26 -0500
In-Reply-To: joda at pdc.kth.se's message of 12 Mar 1997 18:42:13 +0100
Message-Id: <t53rahksjyd.fsf at rover.cygnus.com>
Lines: 30
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
joda at pdc.kth.se (Johan Danielsson) writes:
>> What is the reason behind specifying UDP as the primary protocol?
>> Using "unsafe" protocols will, as mentioned in the draft, require a
>> lot of extra sanity checks.
For the same reason that the main kerberos protocol uses UDP: it
allows the server to be simple and stateless. If modern operating
systems had decent thread implementations, this would be less
important, but TCP multiplexing adds a fair bit of complexity.
>> Also, what about the "message length" and "AP_REQ length" fields? As I
>> see it, these fields limits the whole message to 64k (not that I think
>> that's a major problem), and adds unnecessary information (since the
>> lengths of the AP-REQ and KRB-PRIV are implied by the ASN.1 strings).
If there is consensus on this, I will increase the length fields to 32
bits (and increase the protocol version number, since I already have
an implementation). However, I agree that 64k seems big enough.
As for redundancy, while ASN.1 does encode the length, the
encode/decode functions which the kerberos library uses require that
the length be known ahead of time (at least I think it does; i'm
caught in a maze of cpp macros, all alike). As a general rule, I
prefer to think of ASN.1 encodings as black boxes, since ASN.1 is so
complex. Besides, redundancy is a good thing :-)
Thanks for the comments!
Marc
Received: from ietf.org by ietf.org id aa26121; 12 Mar 97 21:14 EST
Received: from cjc08238.slip.digex.net by ietf.org id aa26044;
12 Mar 97 21:11 EST
Received: from cja00010.slip.digex.net (localhost [127.0.0.1]) by cja00010.slip.digex.net (8.6.11/8.6.9) with ESMTP id VAA00359; Wed, 12 Mar 1997 21:07:41 -0500
Message-Id: <199703130207.VAA00359 at cja00010.slip.digex.net>
To: Tim Salo <salo at msc.edu>
cc: ietf at ietf.org, mike at box.nl
Subject: Re: appending my apologies
In-reply-to: Your message of "Wed, 12 Mar 1997 11:13:23 CST."
<199703121713.LAA01832 at uh.msc.edu>
Reply-to: Ed Levinson <XIson at cnj.digex.net>
X-Mailer: MH 6.8.3
Date: Wed, 12 Mar 1997 21:07:41 -0500
Sender:ietf-request at ietf.org
From: Ed Levinson <xison at cnj.digex.net>
Source-Info: From (or Sender) name not authenticated.
Tim, thanks for a good chuckle and a great wide smile :-> "... she,
he, or it [shit] ...". I rarely read "remove" messages or messages
in the threads they generate. I'm glad to have read yours.
Ed
On Wed, 12 Mar 1997 11:13:23 CST Tim Salo wrote:
> ...
> And finally, I know that somewhere out there, yet another evil twin of
> my ex-VP will be having a bad day, and will send me mail about how I
> was wasting his or her time. And, unfortunately, she, he, or it [shit] will
> probably copy the whole list, so you too, will know that she/he/it
> is having a bad day. Which may only make your day worse. And the
> cycle continues.
> ...
Received: from ietf.org by ietf.org id aa27386; 12 Mar 97 21:46 EST
Received: from callandor.cybercash.com by ietf.org id aa27325;
12 Mar 97 21:45 EST
Received: by callandor.cybercash.com; id VAA23310; Wed, 12 Mar 1997 21:35:56 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma023284; Wed, 12 Mar 97 21:35:19 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA28403; Wed, 12 Mar 97 21:38:24 EST
Date: Wed, 12 Mar 1997 21:38:23 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: ietf at ietf.org
Subject: Export restrictions (Re: call for a new email infrastructure)
In-Reply-To: <3325D3ED.7007 at atr.net>
Message-Id: <Pine.SUN.3.91.970312203308.26881C-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Tue, 11 Mar 1997, Turner W Rentz III wrote:
> Date: Tue, 11 Mar 1997 16:51:41 -0500
> From: Turner W Rentz III <treyr at atr.net>
>
> Leonid Yegoshin wrote:
>
> > ...
> > More over that could you do with export restrictions on this (the) way
> ...
>
> Export restrictions will prohibit RSA keys greater than 40 bits.
> It is my understanding that key length will go up soon.
There are no special munitions type export retrictions from the US for
authentication only schemes, using RSA or other systems, with keys of any
length. There are such restrictions on confidentiality systems. (And there
are a few countries to which all exports from the US require special
permission.)
> T. Rentz, III "The Internet is the Garden of Eden."
> http://www.atr.net/people/treyr
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 aa27491; 12 Mar 97 21:48 EST
Received: from net1.unety.net by ietf.org id aa27445; 12 Mar 97 21:48 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by net1.unety.net (8.7.3/8.7.3) with SMTP id UAA04866; Thu, 13 Mar 1997 20:13:34 -0600 (CST)
Received: by webster.unety.net with Microsoft Mail
id <01BC2F25.E0320080 at webster.unety.net>; Wed, 12 Mar 1997 20:42:18 -0600
Message-ID: <01BC2F25.E0320080 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: 'Phil Karn' <karn at qualcomm.com>
Cc: "ietf at ietf.org" <ietf at ietf.org>
Subject: RE: call for a new email infrastructure
Date: Wed, 12 Mar 1997 20:42:16 -0600
Encoding: 53 TEXT
Source-Info: From (or Sender) name not authenticated.
On Wednesday, March 12, 1997 10:49 AM, Phil Karn[SMTP:karn at qualcomm.com] wrote:
@ Any sender-oriented anti-spam mechanism (sender pays, legal sanctions,
@ etc) will never work. In particular, legal sanctions would have the
@ same fundamental Constitutional and practical problems as the infamous
@ Communications Decency Act. (It amazes me just how many vociferous
@ opponents of the CDA can so easily call for laws against spamming.)
@
I agree....
I was sort of surprised that you did not look down
the road a bit more. The world of distributed object-oriented
technology with active agents and an emphasis on
platforms rather than protocols is closer than you may
think. It will be interesting to see how the IETF deals
with such a major paradigm shift.
In my opinion, this technology will help to solve many
of the problems of the uncivilized IPv4 "core". The core
will evolve to be a low-cost transport network with a
reasonable DNS and reliability and operational integrity
largely handled by major carriers.
Around the edge of this core will grow a new world
that is more immune from the social problems that
now plague the net. This will be similar to the way
suburbs developed around the core cities and for
many people, they can rely on the core but not
really go there.
In a year or two, I predict that people will not
find it to be desirable to plug themselves into
the core, just like people do not find it desirable to
wander around some major cities after dark.
Instead, the collaborative, seemless, environments
built on objects and classes with simple protocols
will offer people the "services" they want. Hopefully,
one of those "services" will be mail processing. If
that occurs then we may end up with a world where
software agents work out the details while people
spend their time on real issues facing the the
real world.
Thanks for your time...
--
Jim Fleming
Unir Corporation
e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)
Received: from cnri by ietf.org id aa28165; 12 Mar 97 22:01 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa27197;
12 Mar 97 22:01 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <XAA16347 at pad-thai.cam.ov.com>; Wed, 12 Mar 1997 23:42:59 GMT
Message-Id: <3.0.32.19970312154438.00946c20 at pop-srvr.cybersafe.com>
X-Sender: matth at pop-srvr.cybersafe.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 12 Mar 1997 15:44:40 -0800
To: bjb at trsvr.tr.unisys.com, cat-ietf at mit.edu, CryptoAPI at listserv.msn.com,
ssl-talk at netscape.com
From: Matt Hur <matt.hur at cybersafe.com>
Subject: Re: GSS-API and SSL - their coexistence, and related issues
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
At 04:33 PM 3/12/97 -0500, Bill Buffam wrote:
8<
>8
>(c) We can apparently embrace Kerberos migration within the SSL
>mechanism, as defined in
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-kerb-cipher-suites-00.txt
>This implies that SSL (or TLS or whatever it becomes) becomes the
>unifying framework within which all future session-oriented security
>mechanisms will live. It appears to set the stage for GSS-API and
>SSL/TLS to compete for the role of unifying orchestrator of
>session-oriented security. The very existence of this draft seems to me
>to be a tacit admission that current SSL techniques are more
>developer-friendly than GSS-API. Perhaps the authors could comment.
>
The Kerberos cipher suite draft does not imply a preference of SSL over
GSS-API. It simply acknowledges a general acceptance of SSL.
We view support for Kerberos cipher suites in SSL as simply a mechanism to
provide more coverage and interoperability for users who are registered
with Kerberos realms. This is especially apparent within the enterprise
environment.
SSL (or TLS) is currently a dominant public key based protocol. Since it
is so easy to add a Kerberos authentication method, it seemed like a
"no-brainer" to add support for Kerberos cipher suites (in that you can get
a big payoff in interoperability - it took about a week and a half to do
our reference implementation).
We are trying to be pragmatic about interoperability (espcially since our
company's primary customers are large enterprises). If an organization has
a Kerberos infrastructure in place, then they should be able to use
Kerberos for authentication to services that are secured via protocols that
have typically utilized public key cryptography for authentication.
Whether this solution leads to a migration to a public key infrastructure
or not is orthogonal to the issue of interoperability. Likewise, if an
organization has a public key infrastructure in place, then they should be
able to use public key credentials to authenticate to Kerberized services
(this is accomplished with PKINIT, another Internet draft with which we
have been intimately involved). Again, whether or not this is a migratory
solution is orthogonal to the issue of interoperability.
We would like to see support for Kerberos cipher suites in SSL/TLS. We
think that this is a pragmatic approach to interoperability in large scale,
real world deployments.
We talked with the folks over at Netscape about supporting Kerberos cipher
suites in their SSL implementation. If you are developing SSL/TLS
implementations, we would like to hear from you, and we would be interested
in providing support for this endeavor. We haven't talked with the folks
at Microsoft yet, but we would appreciate thier input, since they are
developing both Kerberos and SSL/TLS-based solutions as part of their
security infrastructure.
You can download a simple reference implementation from
ftp://nii.isi.edu/pub/ssl-krb.
Regards,
Matt Hur
8<
>8
>--
>
>Bill Buffam
>Unisys, Malvern PA
>bjb at trsvr.tr.unisys.com
>
>
----------------------------------------------------------------
Matt Hur CyberSafe
matt.hur at cybersafe.com 1605 NW Sammamish Road, Suite 310
(206) 391-6000 Issaquah, WA 98027-5378
http://www.cybersafe.com
Received: from cnri by ietf.org id aa28266; 12 Mar 97 22:03 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa27235;
12 Mar 97 22:03 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <AAA17119 at pad-thai.cam.ov.com>; Thu, 13 Mar 1997 00:05:07 GMT
Date: Wed, 12 Mar 1997 19:04:39 -0500
Message-Id: <9703130004.AA00386 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: bjb at trsvr.tr.unisys.com
Cc: cat-ietf at mit.edu, CryptoAPI at listserv.msn.com, ssl-talk at netscape.com
In-Reply-To: Bill Buffam's message of Wed, 12 Mar 1997 16:33:00 -0500,
<3327210C.3FBA at trsvr.tr.unisys.com>
Subject: Re: GSS-API and SSL - their coexistence, and related issues
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Well, here's my take on things.
GSSAPI is the ideal interface between an application and a security
mechanism such as Kerberos, or SPKM (if you want to use public key).
It defines enough of a token-framing protocol so that you can recognize
which GSSAPI mechanism produced a particular GSSAPI token, and we have
convenient meta-protocol definitions (such as SASL) to define how you
can layer GSSAPI on top of a stream-based application protocol.
GSSAPI can also be used as the binary interface into which you can "plug
and play" a security mechanism. So for example, SAP ships its
application without any security code (after all, they are in Germany,
and they don't want to deal with Germany's export control regulations).
Their application can dynamically link with a GSSAPI library which is
provided by MIT in the U.S., and the net result is a secure application
which uses strong cryptography! We're successfully interfacing with SAP
under Unix (OSF/1 and Solaris unix shared libraries), Windows 3.x, 95
and NT (DLL's), and Macintosh (using CFM's).
An application vendor can therefore support multiple security
mechanisms, and not even have to supply a specially linked application,
by using dynamically linked libraries using the GSSAPI as the interface
definition.
It is true that that the GSSAPI isn't necessarily the easist API to
write to. But we don't necessarily need to force application writers to
write to the GSSAPI! For example, if we have a simple library which
implements a meta-protocol such as SASL and makes GSSAPI calls, and
implements a a more familiar API based on STDIO for the application
programmer, we can just let the application programer use that.
Obviously, the simpler API will tradeoff a lot of functionality for
simplicity. However, many applications may not need all of the
functionality, and therefore the complexity, provided by the GSSAPI.
The simpler API can also be OS-dependent, and thus manage the transport
layer for the application as well. It might look a lot like WINSOCK
(ala SSL), although my personal bias is that the STDIO interface might
be easier for programmers.
The issue about OS issues is important --- some operating systems, such
as the Macintosh, really assume that I/O should be done asyncronously,
and they have their own way of handling the asyncronous I/O. Under X11,
for example, you may use an EventLoop; under the Macintosh, you use
callback functions. An API which gets involved with transport issues
needs to make an allowance for how its going to handle async I/O.
This is why I believe the GSSAPI is the ideal, OS-independent interface
point between applications and security mechanisms. There may need to
be some OS-dependent shim code that handles the transport and which is
actually usable by applications protocol. The disconnect that we have
today is that GSSAPI handles the first problem well, and the second one
not at all, and SSL handles the second problem well, but not the first.
- Ted
Received: from cnri by ietf.org id aa05445; 12 Mar 97 23:05 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa28206;
12 Mar 97 23:05 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <AAA16949 at pad-thai.cam.ov.com>; Thu, 13 Mar 1997 00:01:30 GMT
Message-Id: <199703130000.AA26256 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: GSS-API and SSL - their coexistence, and related issues
To: bjb at trsvr.tr.unisys.com
Date: Wed, 12 Mar 1997 19:00:18 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <3327210C.3FBA at trsvr.tr.unisys.com> from "Bill Buffam" at Mar 12, 97 04:33:00 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Bill Buffam wrote:
>
> Requirements
> 1) Mechanism-independent API for applications and middleware to use.
>
> 2) Transport-independent mechanisms
>
> 3) CryptoAlgorithm-independent mechanisms.
>
>
> Possible Options
>
> 1) GSS-API as the mechanism-independent API.
> Issues:
> (a) Application writers seem not to like GSS-API. It seems very
> cumbersome to program.
Once you get used to it, you'll appreciate it simplicity.
I like it.
> (b) SSL wasn't designed to fit under GSS-API, and force fitting it seems
> to require much effort and some compromise.
I haven't read anything about SSL, so I'm mere guessing:
- SSL usually comes with a transport mechanism, GSS-API is without
- SSL is synchronus&blocking, GSS-API is whatever you want
- SSL is stream, GSS-API is message-oriented.
- GSS-API v2 defines security context transfer to other processes,
I don't know if that is defined for SSL
> (c) Popular support for GSS-API seems weak. It's now the native
> interface to Kerberos, but the only other mechanism so far using it is
> Entrust's SPKM (an X.509-based public key mechanism). No other
> developer, to the best of my knowledge, has embraced SPKM. (Can anyone
> from Entrust comment on the uptake of GSS-API in the Entrust user base?)
- OSF DCE 1.1 offers GSS-API,
- Sesame-based products use GSS-API as their (only) native interface.
A year ago our development partners did plan to support SPKM in their
commercial product. Currently they're using their own mechanism,
I don't know when or if they're going to complete their SPKM implementation.
(http://www.secude.com).
> (d) Microsoft has publicly stated a commitment to SSPI (Windows-style
> GSS-API) as its native interface to Kerberos and SSL, yet has been
> silent since the beginning of this discussion questioning the
> feasibility of GSS/SSL coexistence. (Hello Microsoft. Can you comment?)
If they're careful, it should be possible with some glue layer atop
SSPI to talk to native GSS-API v1 Kerberos implementations. I would
really appreciate if they added context transfer capabilities to SSPI,
so that GSS-API v2 becomes a possibility.
>
> 2) Winsock (or similar) as the mechanism-independent API.
> Issues:
> (a) A Winsock-style interface may be ideal for applications that want a
> minimum of aggravation in invoking security functions, but a management
> API will be needed to configure behavior that the application writer
> likely doesn't care about (or doesn't know enough to decide, or should
> by policy be decided at a more global level) (e.g. ciphersuites)
> (b) We just moved the responsibility for organizing the transport
> independence. With GSS-API, the caller is responsible for managing the
> transport. With Winsock (or similar) we're making the SSL layer
> responsible for the transport. This seems to be an advantage. Firstly,
> the application is freed from a lot a tedious state maintenance, and
> sees a much simpler interface. Secondly, in systems that only care about
> TCP/IP, that's the only transport we need to implement. Thirdly, in
> systems that do need to deal with other transports, we make the
> selection and handling of that transport the responsibility of the
> system (not the application) and control its selection through the
> (putative) management interface.
As far as I know, SSL is ALWAYS synchronous and blocking. This is a
serious limitation, because it impacts scalability and reliability.
> (c) We can apparently embrace Kerberos migration within the SSL
> mechanism, as defined in
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-kerb-cipher-suites-00.txt
> This implies that SSL (or TLS or whatever it becomes) becomes the
> unifying framework within which all future session-oriented security
> mechanisms will live. It appears to set the stage for GSS-API and
> SSL/TLS to compete for the role of unifying orchestrator of
> session-oriented security. The very existence of this draft seems to me
> to be a tacit admission that current SSL techniques are more
> developer-friendly than GSS-API. Perhaps the authors could comment.
>
> 3) No standard API. Each mechanism does its own thing.
> Issues:
> (a) Ugh!
>
> Summary - Issues - Musings
> Option 2 looks, in some respects, very attractive. Yet it seems to give
> SSL/TLS the crown jewels as the central nucleus of session-oriented
> security. Is that what we want?
It is probably the most easy and fast way to go for many small and medium
size applications in spite of a some performance, scalability and
reliability issues.
A large application that pushes every available hardware to it's
limits might not be able to accept any one of these problems...
-Martin
Received: from ietf.org by ietf.org id aa06863; 12 Mar 97 23:59 EST
Received: from mail.proper.com by ietf.org id aa06778; 12 Mar 97 23:55 EST
Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA16455; Wed, 12 Mar 1997 20:49:11 -0800 (PST)
X-Sender: paulh at mail.proper.com
Message-Id: <v03101f1aaf4d38c4328d at [165.227.249.100]>
In-Reply-To: <199703130049.QAA17929 at servo.qualcomm.com>
References: <MailManager.858021782.366.mrc at Ikkoku-Kan.Panda.COM> (message
from Mark Crispin on Mon, 10 Mar 1997 11:23:02 -0800 (PST))
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 12 Mar 1997 20:54:50 -0800
To: Phil Karn <karn at qualcomm.com>
Sender:ietf-request at ietf.org
From: Paul Hoffman <paulh at imc.org>
Subject: Re: call for a new email infrastructure
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 4:49 PM -0800 3/12/97, Phil Karn wrote:
>Any sender-oriented anti-spam mechanism (sender pays, legal sanctions,
>etc) will never work. In particular, legal sanctions would have the
>same fundamental Constitutional and practical problems as the infamous
>Communications Decency Act. (It amazes me just how many vociferous
>opponents of the CDA can so easily call for laws against spamming.)
I disagree with you about the constitutionality of (US) laws that will help
control spam (more properly called unsolicitied commercial mail or UCE).
Specficially, I believe that laws that require both labelling and honesty
in return addresses can help control UCE by making filtering at the user
and ISP level more effective. Please see <http://www.imc.org/imc-spam/> for
a reference to a very complete legal review article about what has been and
can be done about UCE. IMC is also starting a mailing list to discuss these
legal issues.
--Paul Hoffman, Director
--Internet Mail Consortium
Received: from cnri by ietf.org id aa07307; 13 Mar 97 0:05 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa01347;
13 Mar 97 0:04 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
