GSSAPI Framework architecture requirement
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GSSAPI Framework architecture requirement
- Subject: GSSAPI Framework architecture requirement
I tried to post this right after the Paris meeting and had a few
odd notices back from the OSF mailer; at the time I interpreted this
as the usual bounce-back symptoms but I've recently come to believe that
this note was not distributed to ANYONE. It contains one of my two proposals
for an addition to RFC8.0 (which we're discussing at the upcoming SIG
in Cupertino)
=============================================================================
REQUIREMENTS FOR GSSAPI FRAMEWORK
Note that the requirements presented below are intended to be cumulative;
that is, R 2 presupposes an implementation which meets R 1; R 3 presupposes
an implementation which meets R 1 and R 2; etc...
>>>>>>>>>>>>>>>>>>> (R 1) IETF GSSAPI Requirement <<<<<<<<<<<<<<<<<<<
GSSAPI was invented to satisfy the following requirement:
>> It must be possible for applications which use insecure transport
>> protocols to assure message integrity, confidentiality, nonrepudiation,
>> and origin/destination authentication through an API. This API must
>> be "generic" in the sense that it must not expose network logon, key
>> distribution and management, credential management, or cryptographic
>> functions to applications, so that it can be implemented "on top of"
>> many different kinds of authentication, integrity, and confidentiality
>> mechanisms.
The current IETF GSSAPI specification, augmented by DCE RFC 5.0,
largely meets this requirement.
An "IETF plain-vanilla" implementation of GSSAPI "on top of" a
particular security mechanism looks like this (note that unless
otherwise stated, a "security mechanism" is assumed to include network
logon, credential distribution and management, key distribution and
management, and crypto functions):
+-----------------------+
: Application :
+-----------------------+
.
.
+----------v------------+
: GSSAPI :
+-----------------------+
: Security Mechanism :
: (e.g. DCE RPC_auth) :
+-----------------------+
>>>>>>>>>>>>>>>>>>> (R 2) Requirement: <<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>> Select Mechanisms Dynamically <<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>> Allow Multiple Simultaneous Mechanisms <<<<<<<<<<<<<<<<<<<
An additional requirement, not described above, is:
>> Applications should be able to select a security mechanism from among
>> the set available on the system at runtime (note that this implies
>> selecting the security server to be used for authentication -- and
>> thus the format and contents of the credentials acquired -- at the
>> time the security mechanism is selected; this can be very important.)
>> Applications should be able to use several security mechanisms at the
>> same time.
An architecture which does NOT meet this requirement is pictured below;
in this architecture, an application has to bind to the copy of GSSAPI
corresponding to the requested mechanism before calling any GSSAPI routine.
This does not allow dynamic selection of mechanisms:
+--------------------------------------------------+
: Application :
+--------------------------------------------------+
. select mech 3
.
+-----------------------+ +--v--------------------+
: GSSAPI : : GSSAPI :
+-----------------------+ +-----------------------+
: Security Mechanism : : Security Mechanism :
: (e.g. DCE RPC_auth) : : (e.g. Netware 4.0) :
+-----------------------+ +-----------------------+
The GSSAPI specification acknowledges that several security mechanisms
might be available "underneath" the API, and it provides some API support
for querying what mechanisms are available and for selecting mechanisms.
The picture below illustrates the intended GSSAPI architecture for
multiple mechanism support:
+--------------------------------------------------+
: Application :
+--------------------------------------------------+
. select mech 3
.
+-----------------------------.--------------------+
: GSSAPI +--------------v---+ :
: : mechanism router : :
: +------------------+ :
: . :
: . :
+-----------------------------.--------------------+
.
.
.
+-----------------------+ +--v--------------------+
: Security Mechanism : : Security Mechanism :
: (e.g. DCE RPC_auth) : : (e.g. Netware 4.0) :
+-----------------------+ +-----------------------+
>>>>>>>>>>>>>>>>>>> (R 3) Requirement: <<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>> Allow Mechanism Registration <<<<<<<<<<<<<<<<<<<
An additional requirement, not described above, is:
>> An independent software vendor must be able to write a security mechanism
>> module (call it "M1") and register it with GSSAPI, with the result that
>> mechanism M1 becomes available for selection by applications.
>> It must be possible for an administrator to specify which mechanism should
>> be the GSSAPI "default" mechanism.
The GSSAPI specification does not provide support for registering mechanisms
and associating them with "mechanism numbers" so that they can be queried or
selected.
Additionally, there is nothing in the specification which describes
how default mechanisms are configured; this could be done as part of the
GSSAPI initialization, or on a user-by-user basis, or in some other way.
To allow mechanism registration, a "GSS-SPI" (*S*ervice *P*rovider
*I*nterface)
would have to be written; this SPI would expose functions for registering
mechanisms, specifying default mechanisms, etc...; this would have the effect
of turning GSSAPI into an "application framework". A possible GSSAPI
framework
architecture is pictured below:
+--------------------------------------------------+
: Application :
+--------------------------------------------------+
. select mech 3
.
+-----------------------------.--------------------+
: GSSAPI +--------------v---+ :
: : mechanism router : :
: +------------------+ :
:------------------------+ . :
: mechanism registration : . :
+-^--^------------------------.--------------------+
. . .
mech := 1 . ......mech := 3......... .
. . .
+-----------------------+ +--v--------------------+
: Security Mechanism : : Security Mechanism :
: (e.g. DCE RPC_auth) : : (e.g. Netware 4.0) :
+-----------------------+ +-----------------------+
If ISVs are going to be encouraged to write their security code with the
intention of registering it with GSSAPI (and so making it available to
GSSAPI-based applications), it will be necessary to provide a "GSS-SPI
environment" with good support for developing security mechanism code.
Requirements R 4 and R 5 describe some required features of this "GSS-SPI
environment".
>>>>>>>>>>>>>>>>>>> (R 4) Requirement: <<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>> Share Credentials among Mechanisms <<<<<<<<<<<<<<<<<<<
Not everyone who wants to develop a secure resource access protocol
(i.e. "mechanism") will want to develop a new authentication protocol
and a new credential format. For example, many distributed resource
managers may want to develop secure non-RPC resource access protocols,
but without having to give up the use of DCE tickets. It would be nice
to support two different types of mechanisms in the GSS-SPI environment:
(A) Mechanisms with "native credentials"
(B) Mechanisms which use "foreign credentials"
We can state this requirement as follows:
>> It must be possible for several security mechanisms with different
>> cryptographic technologies and different available combinations of
>> message confidentiality and message integrity to share the same key
>> distribution and credential distribution mechanisms. It must be
>> possible in particular for several different mechanisms to have
>> access to the same copy of a user's credentials (for example, a
>> user's DCE PTGT).
Note that this requirement is on type-(A) mechanisms, not on GSSAPI or
GSS-SPI; probably the specific DCE requirement here is that the security
runtime must present an API which allows type-(B) mechanisms to manipulate
the credential cache in order to retrieve and use tickets and their
associated session keys. We are NOT asserting here a requirement for
a "generic credential manipulation interface" (which type-(A) mechanisms
would expose and type-(B) mechanisms would call) as part of the GSS-SPI
environment. Such an interface would be very difficult to design, and
is probably better left to a standardization effort after several
mechanisms have become popular.
Note however that the GSS-SPI mechanism registration facility will
probably have to require mechanisms to specify whether they are
type-(A) or type-(B), and, if type-(B), which type-(A) mechanism's
credentials are used. A type-(B) mechanism which depends on a particular
type-(A) credential format should not be allowed to be registered if the
required type-(A) mechanism is not installed.
In order to meet this requirement, security mechanisms whose
credentials need to be made available to other mechanisms must expose
credential management (and probably also key management) APIs which
can be called by other mechanisms; the picture below shows an architecture
which meets this requirement:
+--------------------------------------------------+
: Application :
+--------------------------------------------------+
. select mech 3
.
+-----------------------------.--------------------+
: GSSAPI +--------------v---+ :
: : mechanism router : :
: +------------------+ :
:------------------------+ . :
: mechanism registration : . :
+-^--^------------------------.--------------------+
. . .
mech := 1 . ......mech := 3......... .
. . .
+-----------------------+ +--v--------------------+
: Security Mechanism : : Custom Mechanism :
: (e.g. DCE RPC_auth) : : (e.g. new LU6.2) :
: crypto, msg integ., : +-----------------------+
: msg confid. : .
+-----------------------+ .
. .
. . get tickets,
+---------v-------------+ . session keys
: DCE RPC_auth : .
: <..............
: credential mgmt. :
: session key mgmt. :
+-----------------------+
Unfortunately, DCE does not expose the necessary APIs. It contains
(but does not publish) the Kerberos APIs for credential management
and session key management -- and Kerberos is an industry standard.
Unfortunately, Kerberos gives access only to "plain" tickets, not DCE
privilege tickets. There is no architected or published interface
which gives access to privilege tickets; the interface which is used
to get PAC information out of a ticket stored in the DCE credential
file is "priv_krb_util_authdata_to_pac".
>>>>>>>>>>>>>>>>>>> (R 5) Requirement: <<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>> Separate of Crypto Function <<<<<<<<<<<<<<<<<<<
A requirement not met by the above architecture is:
>> It must be possible to write mechanism code without having to
>> implement crypto function; crypto function should be provided as
>> a system service under an API. Crypto code should be
>> separable from mechanism code so that crypto code can be replaced
>> for exportable versions and so that hardware crypto support can be
>> introduced. Replacement of crypto code and introduction of hardware
>> crypto capability should both be possible without requiring changes
>> to mechanism or application code.
An architecture which might support this mechanism is pictured below.
A generic crypto interface probably needs to be designed if the GSS-SPI
environment is going to be attractive to mechanism developers.
+--------------------------------------------------+
: Application :
+--------------------------------------------------+
. select mech 3
.
+-----------------------------.--------------------+
: GSSAPI +--------------v---+ :
: : mechanism router : :
: +------------------+ :
:------------------------+ . :
: mechanism registration : . :
+-^--^------------------------.--------------------+
. . .
mech := 1 . ......mech := 3......... .
. . .
+-----------------------+ +--v--------------------+
: Security Mechanism : : Custom Mechanism :
: (e.g. DCE RPC_auth) : : (e.g. new LU6.2) :
: crypto, msg integ., : +-----------------------+
: msg confid. : . .
+-----------------------+ . .
. . . .
. . . TKTS, .
. +---------v-------------+ . keys .
. : DCE RPC_auth : . .
. : <........ .
. : credential mgmt. : .
. : session key mgmt. : .
. +-----------------------+ .
. . .
. . .
+-v--------------v------------------------------v--+
: crypto :
+--------------------------------------------------+
>>>>>>>>>>>>>>>> (R 6) Requirement: <<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>> Allow Mechanism Selection by Security QOS <<<<<<<<<<<<<<<<
It may be desirable in a future release to add the following requirement:
>> It should be possible to specify a "security Quality of Service"
>> parameter set and determine what mechanisms are available through
>> GSSAPI which provide the desired quality of service.
So for example one might want to modify the GSS_indicate_mechs()
call to accept input parameters, somewhat along these lines:
GSS_indicate_mechs ( TWO_WAY_AUTHENTICAION |
STRONG_INTEGRITY |
WEAK_PRIVACY )
The return parameter "mech_set" would then contain only the set of
mechanisms which provide two-way authentication, strong message integrity,
and weak message privacy.
--bob
Bob Blakley (internet: blakley at vnet.ibm.com)
IBM Austin, 11501 Burnet Rd. Bldg 903 Rm 5b-03
Phone (512)838-8133 t/l 678-8133, FAX 838-1040
------- End Forwarded Message
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21983;
7 Jul 93 0:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21977;
7 Jul 93 0:47 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa14464; 7 Jul 93 0:47 EDT
Received: by bitsy.MIT.EDU
id AA23460; Wed, 7 Jul 93 00:39:10 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA23454; Wed, 7 Jul 93 00:39:09 EDT
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA22513; Wed, 7 Jul 93 00:39:08 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA13697; Wed, 7 Jul 93 00:39:02 EDT
Date: Wed, 7 Jul 93 00:39:02 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at athena.mit.edu>
Message-Id: <9307070439.AA13697 at tsx-11.MIT.EDU>
To: "John Wray, Digital DPE, 486-5210 01-Jul-1993 1403" <wray at tuxedo.enet.dec.com>
Cc: p.v.mcmahon at rea0803.wins.icl.co.uk, cat-ietf at mit.edu
In-Reply-To: John Wray, Digital DPE, (508) 486-5210 01-Jul-1993 1403's message of Thu, 1 Jul 93 14:11:15 EDT,
<9307011810.AA25453 at us1rmc.bb.dec.com>
Subject: Re: trivial GSSAPI C discrepancy
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Thu, 1 Jul 93 14:11:15 EDT
From: "John Wray, Digital DPE, (508) 486-5210 01-Jul-1993 1403" <wray at tuxedo.enet.dec.com>
> 5.6. gss_delete_sec_context
>
> OM_uint32 gss_delete_sec_context (
> OM_uint32 * minor_status,
> gss_ctx_id_t * context_handle,
> gss_buffer_t output_token)
>
> ....
> context_handle gss_ctx_id_t, modify
> context handle identifying context to
> delete.
I'd also suggest going with this version of gss_delete_sec_context, as
gss_delete_sec_context may very well want to modify/zero out the
context_handle. It should be noted that some implementations (namely,
the current Kerberos V5 implementation) are currently storing the actual
context information in the context_handle data type, as opposed to
making the context_handle a pointer to a structure containing the
information. As far as I know, there is nothing in the GSSAPI spec
which prohibits this, although if there is, I am certainly open to
changing it in my implementation.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22033;
7 Jul 93 0:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22020;
7 Jul 93 0:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14490;
7 Jul 93 0:48 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22000;
7 Jul 93 0:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21941;
7 Jul 93 0:46 EDT
Received: from x400gate.bnr.ca by CNRI.Reston.VA.US id aa14426;
7 Jul 93 0:46 EDT
X400-Received:
by mta x400gate.bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 7 Jul 1993 00:46:13 -0400
X400-Received:
by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 7 Jul 1993 00:45:48 -0400
X400-Received:
by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 6 Jul 1993 20:04:00 -0400
Date: Wed, 7 Jul 1993 00:04:00 +0000
X400-Originator: /DD.ID=PSD05683/G=BNR/I=N/S=Postmaster/@bnr.ca
X400-MTS-Identifier:
[/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.456:07.06.93.04.45.48]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Undeliverable...
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "BNR (N.) Postmaster" <postmast at bnr.ca>
X-Orig-Sender: "BNR (N.) Postmaster" <postmast at bnr.ca>
Message-ID: <"11479 Wed Jul 7 00:45:59 1993"@bnr.ca>
To: ietf at CNRI.Reston.VA.US
Subject: Undeliverable mail.
The message with subject "Re: Keeping working groups open: Was Re: A non
response ...", sent at 19:45:00, Fri May 7/93, was undeliverable to:
David (D.) Liu :Dept 6L31 (BNR)
- delivery timed out after 60 days
It has been delivered to other recipients (if there were any).
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03235;
7 Jul 93 9:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07220;
7 Jul 93 9:27 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03164;
7 Jul 93 9:27 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03025;
7 Jul 93 9:23 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: pip at thumper.bellcore.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-pip-ipit-transition-00.txt
Date: Wed, 07 Jul 93 09:23:05 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307070923.aa03025 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the P. Internet Protocol Working
Group of the IETF.
Title : IP Independent Transition (IPIT) for Pip
Author(s) : P. Francis
Filename : draft-ietf-pip-ipit-transition-00.txt
Pages : 17
This document outlines a transition scheme for moving from IP to Pip. While
this document discusses Pip in particular, it could be applied to any IPng.
The transition scheme discussed here is called IPIT, for IP Independent
Transition. It has been developed to address problems with the IPAE
transition scheme, after which the previous Pip transition scheme was
based.
The shortcomings of IPAE stem from its reliance on IP addresses during the
first phases of transition. The result is that IP-only hosts will not be
able to talk to IPng hosts after IP addresses have depleted. IPIT allows
new Pip systems to talk to IP systems without a globally unique IP address.
As a result, IP address depletion is less likely with IPIT, and IP-only
hosts will be able to talk to Pip hosts forever. In this sense, IPIT is as
much a co-existence scheme as it is a transition scheme.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pip-ipit-transition-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-pip-ipit-transition-00.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-pip-ipit-transition-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pip-ipit-transition-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03237;
7 Jul 93 9:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07219;
7 Jul 93 9:27 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03165;
7 Jul 93 9:27 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02859;
7 Jul 93 9:17 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: namedroppers at nic.ddn.mil
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-dns-common-errors-00.txt
Date: Wed, 07 Jul 93 09:17:08 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307070917.aa02859 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Domain Name System Working
Group of the IETF.
Title : Common DNS Errors and Suggested Fixes
Author(s) : A. Kumar, J. Postel, C. Neuman,
P. Danzig, S. Miller
Filename : draft-ietf-dns-common-errors-00.txt
Pages : 9
This memo describes common errors seen in DNS implementations and suggests
some fixes. Where applicable, violations of recommendations from RFC 1034
and RFC 1035 are mentioned. The memo also describes, where relevant, the
algorithms followed in BIND (versions 4.8.3 and 4.9 which the authors
referred to) to serve as an example.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-dns-common-errors-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-dns-common-errors-00.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-dns-common-errors-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dns-common-errors-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03265;
7 Jul 93 9:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07218;
7 Jul 93 9:27 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03163;
7 Jul 93 9:27 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02984;
7 Jul 93 9:22 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-wnils at ucdavis.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-wnils-whois-lookup-00.txt
Date: Wed, 07 Jul 93 09:22:52 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307070922.aa02984 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Whois and Network Information
Lookup Service Working Group of the IETF.
Title : Whois and Network Information Lookup Service Whois++
Author(s) : J. Gargano, K. Weiss
Filename : draft-ietf-wnils-whois-lookup-00.txt
Pages : 6
Abstract not provided.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-wnils-whois-lookup-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-wnils-whois-lookup-00.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-wnils-whois-lookup-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-wnils-whois-lookup-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03310;
7 Jul 93 9:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07288;
7 Jul 93 9:28 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03236;
7 Jul 93 9:28 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03000;
7 Jul 93 9:23 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: madman at innosoft.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-madman-dsa-mib-01.txt
Date: Wed, 07 Jul 93 09:22:43 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307070923.aa03000 at IETF.CNRI.Reston.VA.US>
--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 : DSA Monitoring MIB
Author(s) : G. Mansfield, S. Kille
Filename : draft-ietf-madman-dsa-mib-01.txt
Pages : 16
This document defines an MIB for monitoring Directory System Agents [DSA],
a component of the OSI Directory. The DSAmib will be used in conjunction
with the application-mib for monitoring DSAs.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-madman-dsa-mib-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-madman-dsa-mib-01.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-madman-dsa-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-madman-dsa-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04531;
7 Jul 93 10:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11949;
7 Jul 93 10:11 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04491;
7 Jul 93 10:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04271;
7 Jul 93 10:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11776;
7 Jul 93 10:08 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04258;
7 Jul 93 10:08 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Erik-Jan.Bos at surfnet.nl
Subject: July IETF: Current Weather Report for Amsterdam
Date: Wed, 07 Jul 93 10:08:17 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9307071008.aa04258 at IETF.CNRI.Reston.VA.US>
The weather forecast can be reached by gopher-ing to
gopher.nic.surfnet.nl [192.87.46.3]. From the main menu you choose the
menu item "Amsterdam IETF information". Currently the weather forecast is
menu item 21.
Please find below the first issue of the weather report, which will be
updated regularly.
WEATHER FORCAST FOR THE NETHERLANDS
Last updated: 07 Jul 93 09:00 UTC+0200 by EJB
Date ----------> Thu 8 Fri 9 Sat10 Sun11 Mon12
Sunshine (%) 40 30 20 30 50
Probability
Rain (%) 10 50 80 50 30
Temperature:
- - Minimum (C) 12 15 13 12 11
(F) 53 59 55 53 51
- - Maximum (C) 21 22 18 18 18
(F) 69 71 64 64 64
Wind:
- - Direction SW SW SW SW W
- - Speed 4 4 5 4 4
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04545;
7 Jul 93 10:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11955;
7 Jul 93 10:11 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04492;
7 Jul 93 10:11 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04301;
7 Jul 93 10:08 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at ucdavis.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-pppext-isdn-01.txt
Date: Wed, 07 Jul 93 10:08:34 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307071008.aa04301 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : PPP over ISDN
Author(s) : W. Simpson
Filename : draft-ietf-pppext-isdn-01.txt
Pages : 6
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
This document describes the use of PPP over Integrated Services Digital
Network (ISDN) circuits.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pppext-isdn-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-pppext-isdn-01.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-pppext-isdn-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-isdn-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04549;
7 Jul 93 10:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11979;
7 Jul 93 10:11 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04494;
7 Jul 93 10:11 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04323;
7 Jul 93 10:08 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at ucdavis.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-pppext-frame-relay-01.txt
Date: Wed, 07 Jul 93 10:08:44 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307071008.aa04323 at IETF.CNRI.Reston.VA.US>
--NextPart
Note: This filename used to be called as "draft-ietf-pppext-fr-00.txt".
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : PPP in Frame Relay
Author(s) : W. Simpson
Filename : draft-ietf-pppext-frame-relay-01.txt
Pages : 6
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
This document describes the use of Frame Relay for framing PPP encapsulated
datagrams.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pppext-frame-relay-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-pppext-frame-relay-01.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-pppext-frame-relay-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-frame-relay-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04553;
7 Jul 93 10:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11985;
7 Jul 93 10:11 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04496;
7 Jul 93 10:11 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04359;
7 Jul 93 10:09 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: atm at sun.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-atm-classic-ip-01.txt
Date: Wed, 07 Jul 93 10:08:57 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307071009.aa04359 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP over Asynchronous Transfer
Mode Working Group of the IETF.
Title : Classical IP and ARP over ATM
Author(s) : M. Laubach
Filename : draft-ietf-atm-classic-ip-01.txt
Pages : 12
This memo describes an initial application of classical IP and ARP in an
ATM network environment configured as a logical IP subnetwork, or "LIS".
This memo does not preclude the subsequent development of ATM technology
into areas other than an LIS; specifically, as single ATM networks grow to
replace many ethernet local LAN segments and as these networks become
globally connected, the application of IP and ARP will be treated
differently. This document considers only the application of ATM a as a
direct replacement for the "wires" and local LAN segments connecting IP
end-stations and routers. Issues raised by MAC level bridging are beyond
the scope of this paper.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-atm-classic-ip-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-atm-classic-ip-01.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-atm-classic-ip-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-atm-classic-ip-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05432;
7 Jul 93 10:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12687;
7 Jul 93 10:27 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05387;
7 Jul 93 10:27 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04994;
7 Jul 93 10:23 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-osi-x400ops at cs.wisc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-x400ops-tbl-dist-part1-01.txt
Date: Wed, 07 Jul 93 10:23:15 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307071023.aa04994 at IETF.CNRI.Reston.VA.US>
--NextPart
NOTE: This Internet-Draft is one part of an update to the
Internet-Draft "draft-ietf-x400ops-tbl-dist-00". In
the process of updating draft-ietf-x400ops-tbl-dist,
the Working Group decided to split it into two parts.
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the X.400 Operations Working
Group of the IETF.
Title : Mail based file distribution Part 1:
Dialog between two nodes
Author(s) : M. Kaittola
Filename : draft-ietf-x400ops-tbl-dist-part1-01.txt
Pages : 38
Mapping between X.400 and Internet mail and X.400 routing are normally done
using a table-based approach. In practise tables are normal (ASCII) files.
In order to function properly tables must be coordinated carefully. One
major problem is the lack of automated procedures. This memo - together
with it's companion document - proposes one possible solution. This memo
discusses the transactions between two nodes, while the companion document
discusses the over-all structure aspects.
The same solution can be used to transport binary files. This way it is
possible to mirror an entire archive with an e-mail only connectivity.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-x400ops-tbl-dist-part1-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-x400ops-tbl-dist-part1-01.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-x400ops-tbl-dist-part1-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-x400ops-tbl-dist-part1-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05452;
7 Jul 93 10:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12703;
7 Jul 93 10:27 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05390;
7 Jul 93 10:27 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05041;
7 Jul 93 10:23 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-osi-x400ops at cs.wisc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-x400ops-tbl-dist-part2-01.txt
Date: Wed, 07 Jul 93 10:23:53 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307071023.aa05041 at IETF.CNRI.Reston.VA.US>
--NextPart
NOTE: This Internet-Draft is one part of an update to the
Internet-Draft "draft-ietf-x400ops-tbl-dist-00". In
the process of updating draft-ietf-x400ops-tbl-dist,
the Working Group decided to split it into two parts.
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the X.400 Operations Working
Group of the IETF.
Title : Mail based file distribution Part 2: Over-all structure
Author(s) : M. Kaittola
Filename : draft-ietf-x400ops-tbl-dist-part2-01.txt
Pages : 9
Mapping between X.400 and Internet mail and X.400 routing are normally done
using a table-based approach. In practise tables are normal (ASCII) files.
In order to function properly tables must be coordinated carefully. One
major problem is the lack of automated procedures. This memo - together
with it's companion document - proposes one possible solution. This memo
discusses the over-all structure aspects, while the companion document
discusses the transactions between two nodes.
The same solution can be used to transport binary files. This way it is
possible to mirror an entire archive with an e-mail only connectivity.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-x400ops-tbl-dist-part2-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-x400ops-tbl-dist-part2-01.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-x400ops-tbl-dist-part2-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-x400ops-tbl-dist-part2-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05454;
7 Jul 93 10:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12711;
7 Jul 93 10:27 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05393;
7 Jul 93 10:27 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05155;
7 Jul 93 10:24 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at ucdavis.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-pppext-x25-01.txt
Date: Wed, 07 Jul 93 10:24:28 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307071024.aa05155 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : PPP in X.25
Author(s) : W. Simpson
Filename : draft-ietf-pppext-x25-01.txt
Pages : 6
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
This document describes the use of X.25 for framing PPP encapsulated
datagrams.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pppext-x25-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-pppext-x25-01.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-pppext-x25-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-x25-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05492;
7 Jul 93 10:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05470;
7 Jul 93 10:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12715;
7 Jul 93 10:27 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05396;
7 Jul 93 10:27 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05100;
7 Jul 93 10:24 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at ucdavis.edu
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-pppext-lcp-00.txt
Date: Wed, 07 Jul 93 10:24:04 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307071024.aa05100 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : The Point-to-Point Protocol (PPP)
Author(s) : W. Simpson
Filename : draft-ietf-pppext-lcp-00.txt
Pages : 60
The Point-to-Point Protocol (PPP) provides a method for transmitting
multi-protocol datagrams over point-to-point links. PPP is comprised of
three main components:
1. A method for encapsulating multi-protocol datagrams.
2. A Link Control Protocol (LCP) for establishing, configuring,
and testing the data-link connection.
3. A family of Network Control Protocols (NCPs) for establishing and
configuring different network-layer protocols.
This document defines the PPP organization and methodology,
together with the PPP Link Control Protocol (LCP), an extensible option
negotiation protocol which is able to negotiate a rich assortment of
configuration parameters and provides additional management functions.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pppext-lcp-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-pppext-lcp-00.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-pppext-lcp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-lcp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05510;
7 Jul 93 10:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12765;
7 Jul 93 10:28 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05478;
7 Jul 93 10:28 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05133;
7 Jul 93 10:24 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at ucdavis.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-pppext-hdlc-framing-00.txt
Date: Wed, 07 Jul 93 10:24:20 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307071024.aa05133 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : PPP HDLC Framing
Author(s) : W. Simpson
Filename : draft-ietf-pppext-hdlc-framing-00.txt
Pages : 19
The Point-to-Point Protocol (PPP) provides a method for transmitting
multi-protocol datagrams over point-to-point links.
This document describes the use of HDLC for framing PPP encapsulated
datagrams.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pppext-hdlc-framing-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-pppext-hdlc-framing-00.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-pppext-hdlc-framing-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-hdlc-framing-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05556;
7 Jul 93 10:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12799;
7 Jul 93 10:28 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05532;
7 Jul 93 10:28 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05309;
7 Jul 93 10:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: apple-ip at apple.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-appleip-kip-gateway-00.txt, .ps
Date: Wed, 07 Jul 93 10:25:43 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307071025.aa05309 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP over AppleTalk Working
Group of the IETF.
Title : KIP AppleTalk/IP Gateway Functionality
Author(s) : P. Budne
Filename : draft-ietf-appleip-kip-gateway-00.txt, .ps
Pages : 40
This memo was started as an effort to describe ``IPTalk'' for the
AppleTalk-IP Working Group of the Internet Engineering Task Force (IETF).
It became apparent that since no protocol standard or description existed
that implementation specific information was unavoidable. KIP is the
prototypical AppleTalk/IP Gateway implementation and is available in source
form. KIP's functionality forms the basis for many commercial products
available today.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-appleip-kip-gateway-00.txt".
Or
"get draft-ietf-appleip-kip-gateway-00.ps".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-appleip-kip-gateway-00.txt".
Or
"SEND draft-ietf-appleip-kip-gateway-00.ps".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-appleip-kip-gateway-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-appleip-kip-gateway-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05720;
7 Jul 93 10:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12961;
7 Jul 93 10:31 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05709;
7 Jul 93 10:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05576;
7 Jul 93 10:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12829;
7 Jul 93 10:29 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05557;
7 Jul 93 10:29 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Megan Davies Walnut <mwalnut at CNRI.Reston.VA.US>
Subject: July IETF: CHASSIS WG CANCELLED
Date: Wed, 07 Jul 93 10:29:00 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9307071029.aa05557 at IETF.CNRI.Reston.VA.US>
Chassis MIB
Network Management Area
The Chassis MIB Working Group scheduled to meet on Wednesday, 14 July
during the 1330-1530 session has been cancelled.
Megan
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05744;
7 Jul 93 10:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12971;
7 Jul 93 10:31 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05734;
7 Jul 93 10:31 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05613;
7 Jul 93 10:29 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: pip at thumper.bellcore.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-pip-dns-01.txt
Date: Wed, 07 Jul 93 10:29:57 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307071029.aa05613 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the P. Internet Protocol Working
Group of the IETF.
Title : Use of DNS with Pip
Author(s) : P. Francis, S. Thomson
Filename : draft-ietf-pip-dns-01.txt
Pages : 16
Pip is an internet protocol intended as the replacement for IP version 4.
Pip is a general purpose internet protocol, designed to handle all
forseeable internet protocol requirements. This specification describes
the use of DNS to support Pip. Because Pip carries IDs and addresses
separately, and because Pip Addresses are variable length, DNS must be
modified to support Pip. Also, Pip addresses are more likely to change than
IP addresses. To enable DNS to still cache aggressively in the presence of
address changes, we propose adding functionality to DNS to allow resolvers
to ask for later versions of information when previously returned
information is found to be out-of-date. In addition to these necessary
modifications, we have chosen to add new information to DNS to support
transition and to support Pip features, such as policy routing, mobile
hosts and routing through Public Data Networks. Later multicast support
will be added as well.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pip-dns-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-pip-dns-01.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-pip-dns-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pip-dns-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06106;
7 Jul 93 10:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13589;
7 Jul 93 10:48 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06087;
7 Jul 93 10:48 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04282;
7 Jul 93 10:08 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at ucdavis.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-pppext-lcpext-02.txt
Date: Wed, 07 Jul 93 10:08:22 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307071008.aa04282 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : PPP LCP Extensions
Author(s) : W. Simpson
Filename : draft-ietf-pppext-lcpext-02.txt
Pages : 20
The Point-to-Point Protocol (PPP) provides a standard method of
encapsulating Network Layer protocol information over point-to-point links.
PPP defines an extensible Link Control Protocol (LCP) for establishing,
configuring, and testing the data-link connection. This document defines
several additional LCP features which have been suggested over the past
year.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pppext-lcpext-02.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-pppext-lcpext-02.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-pppext-lcpext-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-lcpext-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06209;
7 Jul 93 10:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13803;
7 Jul 93 10:50 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06185;
7 Jul 93 10:50 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06104;
7 Jul 93 10:48 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: pip at thumper.bellcore.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-pip-ipit-transition-00.txt
Date: Wed, 07 Jul 93 10:48:39 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307071048.aa06104 at IETF.CNRI.Reston.VA.US>
--NextPart
Note: This announcement is being re-sent with a revised abstract.
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the P. Internet Protocol Working
Group of the IETF.
Title : IP Independent Transition (IPIT) for Pip
Author(s) : P. Francis
Filename : draft-ietf-pip-ipit-transition-00.txt
Pages : 17
This document outlines a transition scheme for moving from IP to Pip. While
this document discusses Pip in particular, it could be applied to any IPng.
The transition scheme discussed here is called IPIT, for IP Independent
Transition. It has been developed to address problems with the IPAE
transition scheme, after which the previous Pip transition scheme was
based.
The shortcomings of IPAE stem from its reliance on IP addresses during the
first phases of transition. The result is that IP-only hosts will not be
able to talk globally to IPng hosts after IP addresses have depleted (they
will only be able to talk intra-domain). IPIT allows new Pip systems to
talk to IP systems without a globally unique IP address. As a result, IP
address depletion is less likely with IPIT, and IP-only hosts will be able
to talk to Pip hosts forever. In this sense, IPIT is as much a
co-existence scheme as it is a transition scheme.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pip-ipit-transition-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-pip-ipit-transition-00.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-pip-ipit-transition-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pip-ipit-transition-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06968;
7 Jul 93 11:22 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14807;
7 Jul 93 11:22 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06952;
7 Jul 93 11:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06902;
7 Jul 93 11:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14752;
7 Jul 93 11:20 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06891;
7 Jul 93 11:20 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: July IETF: WGChairs Training
Date: Wed, 07 Jul 93 11:20:45 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9307071120.aa06891 at IETF.CNRI.Reston.VA.US>
Mon., 12 July 1993 0800-0900 Room O
Wed., 14 July 1993 0800-0900 Room O
Training sessions for new (and old) working group chairs will be
repeated at the Amsterdam IETF. The same session will be given
Monday, 8am
and then repeated
Wednesday, 8am.
Attendance is eagerly open to all, but the session is primarily
intended to provide orientation and guidance about the management of
the working group process.
Dave
Chairing a working group is not all fame and glory. Most experienced
chairs can be distinguished by the hollow look in their eyes from
trying to walk the fine line between being fair to working group
members, while still making forward progress. They have had the
pleasure of doing this while receiving only informal guidance from
other, experienced members of the IETF.
This session will attempt to provide a cohesive view of the
responsibilities and authorities of a working group chair. As always,
there will be debate about whatever is presented. I fully expect the
training session to show the same dynamics as a working group.
In terms of content, the training session will review the formal
structure of the IETF, the formal process for creating working
groups and standards-track specifications and will then venture into
the dangerous territory of building rough concensus within a reasonable
amount of time.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10092;
7 Jul 93 14:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10085;
7 Jul 93 14:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21274;
7 Jul 93 14:25 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10075;
7 Jul 93 14:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09991;
7 Jul 93 14:23 EDT
Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa21212;
7 Jul 93 14:23 EDT
Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7)
id <AA05116> for ietf at cnri.reston.va.us; Wed, 7 Jul 93 14:23:45 EDT
Received: by tsuchiya.bellcore.com (4.1/4.7)
id <AA18449> for ietf at cnri.reston.va.us; Wed, 7 Jul 93 14:23:44 EDT
Date: Wed, 7 Jul 93 14:23:44 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Paul Francis--formerly Tsuchiya <francis at thumper.bellcore.com>
Message-Id: <9307071823.AA18449 at tsuchiya.bellcore.com>
To: ietf at CNRI.Reston.VA.US
Subject: Pip demo schedule
The Pip demo will be held at 15:40, Monday through Thursday.
This is 10 minutes after the beginning of the afternoon break.
Auto-configuration and Auto-reconfiguration will be demo'd.
We will show a Pip host booting and automatically obtaining
its address. We'll then start up a telnet session, modify
the address of the router, and show the host obtaining the
new address without dropping the telnet session.
After the demo, and at various other times during IETF,
people will be able to ping and traceroute Pip sites on
the Pbone and any IP site.
PF
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10266;
7 Jul 93 14:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21440;
7 Jul 93 14:30 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10245;
7 Jul 93 14:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10190;
7 Jul 93 14:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21378;
7 Jul 93 14:28 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10185;
7 Jul 93 14:28 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Paul Francis--formerly Tsuchiya <francis at thumper.bellcore.com>
Subject: July IETF: Pip demo schedule
Date: Wed, 07 Jul 93 14:28:44 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9307071428.aa10185 at IETF.CNRI.Reston.VA.US>
The Pip demo will be held at 15:40, Monday through Thursday.
This is 10 minutes after the beginning of the afternoon break.
Auto-configuration and Auto-reconfiguration will be demo'd.
We will show a Pip host booting and automatically obtaining
its address. We'll then start up a telnet session, modify
the address of the router, and show the host obtaining the
new address without dropping the telnet session.
After the demo, and at various other times during IETF,
people will be able to ping and traceroute Pip sites on
the Pbone and any IP site.
PF
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11834;
7 Jul 93 15:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11826;
7 Jul 93 15:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23620;
7 Jul 93 15:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11805;
7 Jul 93 15:35 EDT
Received: from othello.admin.kth.se by IETF.CNRI.Reston.VA.US id aa11659;
7 Jul 93 15:32 EDT
Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b)
id AA18365; Wed, 7 Jul 93 21:33:39 +0200
Received: by mercutio.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0)
id AA15862; Wed, 7 Jul 93 21:30:58 +0200
Date: Wed, 7 Jul 93 21:30:58 +0200
Message-Id: <9307071930.AA15862 at mercutio.admin.kth.se>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Olle Jarnefors <ojarnef at admin.kth.se>
To: ietf at IETF.CNRI.Reston.VA.US
Cc: Olle Jarnefors <ojarnef at admin.kth.se>
Reply-To: Olle Jarnefors <ojarnef at admin.kth.se>
Subject: Document list: domains, mail, netnews, NIR
DOCUMENT LIST: DOMAINS, MAIL, NETNEWS, NIR
-- Compiled by Olle Jarnefors, Royal Institute of Technology,
-- Sweden <ojarnef at admin.kth.se>, 7 July 1993
Inspired by Appendix A of Marshal T. Rose's book
_The Internet Message. Closing the Book with Electronic Mail_
(Prentice-Hall, 1993, ISBN 0-13-092941-7), I have compiled the
following list of freely available documents relevant for
electronic mail and networked information retrieval on the
Internet.
I would very much appreciate any additions or corrections of
this list. I'm acutely aware of the incomplete coverage of the
NIR field. Please write to <ojarnef at admin.kth.se>.
Sources given in the list are of four kinds:
-- Name starts with "1": administrative information about the
IETF, available by anonymous FTP, e.g. from cnri.reston.va.us.
-- Name starts with "d-": abbreviated file name for an Internet
Drafts, where "d-" = "draft-" and ".txt" should be appended,
available by anonymous FTP, e.g. from ds.internic.net (the
last two digits indicates the version of the Internet Draft).
-- RFCs, available in plain text form or, sometimes, PostScript
form by anonymous FTP, e.g. from nis.nsf.net (there is only
one version of an RFC).
-- Other name: document available by anonymous FTP from
othello.admin.kth.se in directory pub/misc/ojarnef, in plain
text form only (the date in brackets indicates the version
of the document). Files are available in both compress:ed
(file name suffix: .Z) and uncompressed form.
-------------------------------------------------------------------------------
Subject Content Source
-------------------------------------------------------------------------------
General Overview of IETF 1ietf-description.txt
The Tao of IETF RFC 1391
IETF WG: procedures d-ietf-iesg-wgguidelines-01
Rules for IETF BOFs 1bof-procedures.txt
Rules for Internet Drafts 1id-guidelines.txt
Rules for RFCs RFC 1111
Overview of areas 1wg-summary.txt
Overview of WGs 1wg-summary-by-acronym.txt
Internet standards RFC 1410
Overview of User Services area 1user-services.txt
Domains DNS: concepts RFC 1034
DNS: implementation RFC 1035
Host Requirements: domains RFC 1123 (part)
New RR-types RFC 1183
Simple mess. Message Send Protocol 2 RFC 1312
Mail before MIME The SMTP protocol RFC 821
Format of messages RFC 822
Host Requirements: mail RFC 1123 (part)
SMTP on X.25 RFC 1090
Mail routing and DNS RFC 974
Duplicate messages and SMTP RFC 1047
Older encapsulation format RFC 934
Older Content-Type: RFC 1049
Encoding: structuring RFC 1154
Format for digests RFC 1153
The UUCP protocol RFC 976
MIME Format of body d-ietf-822ext-mime2-04
Format of header d-ietf-822ext-mime-part2-01
Mailcap files d-borenstein-mailcap2-00
Content-MD5: d-ietf-822ext-md5-02
Content-Disposition: content-disposition.txt (9306)
Content-Types Text/Enriched d-ietf-822ext-text-enriched-02
Text/Simplemail simplemail-spec.txta (930324)
Netfax format RFC 1314
MacMIME macmime.txt (930304)
For MS Windows d-weatherley-mswindows-mime-00
Character sets Mnemonics RFC 1345
Japanese c.s. for MIME RFC 1468
Korean c.s. for MIME d-chon-korean-encoding-00
Hebrew c.s. for MIME d-nussbacher-hebrew-encoding-00
Vietnamese character sets RFC 1456
PEM PEM part 1: procedures RFC 1421
PEM part 2: key management RFC 1422
PEM part 3: algorithms RFC 1423
PEM part 4: key certification RFC 1424
MD2 algorithm RFC 1319
MD5 algorithm RFC 1321
MIME and PEM d-ietf-pem-mime-02
SMTP extensions Framework RFC 1425
8-bit transport RFC 1426
Decl. of message size RFC 1427
Folklore d-onions-smtp-knowledge-00
Mail servers Maint. of large mailing lists RFC 1211
Mail based servers d-houttuin-mailservers-01
CREN req. on m.l. software ip-listserv.txt (930513)
LISTSERV protocol RFC 1429
Netnews THe NNTP protocol RFC 977
Format of articles RFC 1036
Revision of NNTP d-ietf-nntp-news-01
Mail gateways Message header munging RFC 886
Restricted encoding of RFC 822 RFC 1137
MIME for mail gateways RFC 1344
Just-send-8bit <-> MIME RFC 1428
X.400/Internet Overview d-houttuin-rfc1327-tutor-02
X.400 <-> Internet RFC 1327
X.400'88 -> X.400'84 RFC 1328
Message body mapping d-ietf-mimemhs-mapping-02
Equivalence table d-ietf-mimemhs-body-equival-02
Character sets in X.400 d-ietf-x400ops-charactersets-03
Language and character sets d-alvestrand-lang-char-00
Postmaster in X.400 d-ietf-x400ops-postmaster-01
MIME <-> X.400'84 d-ietf-mimemhs-harpoon-03
POP3 The POP3 protocol RFC 1460
POP3 for discussion groups RFC 1082
IMAP2 The IMAP2 protocol RFC 1176
The IMAP2bis protocol imap2bis.txt (9212)
The IMSP protocol imsp.txt (9306)
Decentr. of UAs PCMAIL (The DMSP protocol) RFC 1056
The MPP protocol RFC 1204
The IMAP3 protocol RFC 1203
The RMC protocol RFC 1339
Directory serv. The WHOIS protocol RFC 954
The Finger protocol RFC 1288
NIR: general Status report on NIR d-ietf-nir-status-report-00
Vision of integrated inform. d-ietf-iiir-vision-00
Kunze: resource citations kunze.doc.txt (930326)
Lynch: framework for URIs lynch.overview.txt (930324)
Uniform Resource Locators d-ietf-uri-url-00
Uniform Resource Names d-ietf-uri-resource-names-00
Resource transponders d-ietf-iiir-transponders-00
FTP The FTP protocol RFC 959
Host Requirements: FTP RFC 1123 (part)
Guide to FTP site administr. draft.part.I (921014)
Publishing with anonymous FTP anon-ftp-publ.txt (9306)
Gopher The Gopher protocol RFC 1436
World Wide Web Hypertext markup language d-ietf-iiir-html-00
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12547;
7 Jul 93 16:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24520;
7 Jul 93 16:00 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12534;
7 Jul 93 16:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12473;
7 Jul 93 15:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24452;
7 Jul 93 15:58 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12467;
7 Jul 93 15:58 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Steve DeJarnett <steve at ibmpa.awdpa.ibm.com>
Subject: July IETF: ST-II FUTURE DIRECTIONS BOF (st2)
Date: Wed, 07 Jul 93 15:58:52 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9307071558.aa12467 at IETF.CNRI.Reston.VA.US>
July 1993 IETF Meeting in Amsterdam
BOF Session on
ST-II FUTURE DIRECTIONS
(ST2BOF)
Internet Area
The above BOF is scheduled from 0900 to 1200 on Tuesday, July 13. Exact
location will be available in Amsterdam.
BOF Agenda:
1. Introduction
2. Existing implementation overviews
3. Identify possible protocol changes and extensions
- Update RFC 1190 to more-clearly specify ST-II
- Timestamps
- Hello
- Reason codes
- Target-initiated joining of connections
4. Goals for future work
BOF Abstract
============
Interest in networked multimedia has grown dramatically in the past
2 years, especially with the increased use of the MBONE. IETF interest is
definitely increasing, as is evidenced by the AVT working group, the new
mmusic working group, and the rem-conf metalist.
As groups start to address pieces of the multimedia puzzle, the desire
to use existing infrastructure is high and quite understandable. As David
Clark pointed out at his BOF at the Columbus IETF, however, there needs to be
some specialized functions added to routers and hosts to efficiently deal with
networked multimedia. BOFs to address resource reservation, flow specs, and
so forth are certainly coming. However, one protocol developed by the IETF has
been conspicuously absent from most discussions -- ST-II. ST-II is at the
heart of the German BERKOM project which will be used to link the existing
government offices in Bonn with the new offices in Berlin. ST-II also forms
the basis of the Defense Simulation Internet, and IBM has been working on some
new products that will use ST-II to provide the networking support for
multimedia. Thus, there is certainly industry interest in ST-II today.
The purpose of this BOF would be to find out what level of interest
exists in ST-II, how ST-II might be used as the network layer under RTP and
other transport protocols, what extensions to ST-II might be desired or
required given the current level of experience with multimedia networking, and
what the future of ST-II is, especially with regard to the IESG standards
track.
During the BOF we would like implementors to present a very brief
overview of their implementation, focusing on areas where you diverged from the
specification or where you chose not to implement a certain feature. No more
than 1 hour will be alloted for implementation discussions.
Given the experience that has been gained in these implementations and
the fact that people may start to use ST-II in production environments in the
near future, a review of the current status of ST-II seems warranted. One
desired outcome of this BOF (and any subsequent working group) would be a
version of ST-II suitable for standards track consideration.
Co-chairs for the BOF will be Luca Delgrossi from IBM's European
Networking Center in Heidelberg, Germany, and Steve DeJarnett from IBM's
Personal Software Products division in Mountain View, CA.
- ----
Steve DeJarnett Internet: steve at ibmpa.awdpa.ibm.com
IBM PS Multimedia Mountain View IBM IPNET: steve at ibmpa.awdpa.ibm.com
(415) 694-3896 IBM VNET: dejarnet at almaden (only if you must)
These opinions are my own. I doubt IBM wants them.......
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13045;
7 Jul 93 16:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13037;
7 Jul 93 16:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24877;
7 Jul 93 16:13 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13025;
7 Jul 93 16:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12961;
7 Jul 93 16:11 EDT
Received: from trystero.malamud.com by CNRI.Reston.VA.US id aa24791;
7 Jul 93 16:11 EDT
Received: by trystero.malamud.com
(5.65/IDA-1.2.8c) id AA12448; Wed, 7 Jul 93 16:14:05 -0400
Date: Wed, 7 Jul 93 16:14:05 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Carl Malamud <carl at trystero.malamud.com>
Message-Id: <9307072014.AA12448 at trystero.malamud.com>
To: ietf at CNRI.Reston.VA.US
Subject: Congressional Hearings
Org: Internet Multicasting Service
Congressman Edward J. Markey has asked that the July 26 On-Line
Hearings be delayed until October or November until issues regarding
the propriety of private corporate donations to the congressional
infrastructure are resolved. While it is clearly allowable for
a corporation to bring in computers if they are testifying, there
is as yet no precedent for an on-line congressional hearing and
the Subcommittee and the Congressman would like to make sure that
any issues are carefully examined.
I will be posting a personal note shortly.
Carl Malamud
Internet Multicasting Service
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13290;
7 Jul 93 16:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13282;
7 Jul 93 16:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25375;
7 Jul 93 16:25 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13272;
7 Jul 93 16:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13233;
7 Jul 93 16:24 EDT
Received: from trystero.malamud.com by CNRI.Reston.VA.US id aa25303;
7 Jul 93 16:24 EDT
Received: by trystero.malamud.com
(5.65/IDA-1.2.8c) id AA12542; Wed, 7 Jul 93 16:26:24 -0400
Date: Wed, 7 Jul 93 16:26:24 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Carl Malamud <carl at trystero.malamud.com>
Message-Id: <9307072026.AA12542 at trystero.malamud.com>
To: ietf at CNRI.Reston.VA.US
Subject: Congressional Hearings
Org: Internet Multicasting Service
I wanted to explain a bit more my understanding of why we
are delaying the congressional hearings. Please be very
clear that I do not represent the committee and that this
explanation is being sent in my capacity as the organizer
of the Internet Town Hall.
The Internet Town Hall depends on voluntary donations from a
large number of parties. For this Internet Town Hall, we've
had a tremendous outpouring of support from groups such as
O'Reilly & Associates, Sun Microsystems, Cisco, ARPA, Empirical
Tools and Technologies, UUNET, Metropolitan Fiber Systems,
and many others.
The purpose of this broad coalition is to demonstrate how the
Internet works and how the Internet can be made to work in the
congressional process. We wanted to make the point that there
exists a general-purpose infrastructure that allows everything
from email to IRC chat to WAIS databases to the World Wide Web
to be accessed.
One of the key things we wanted to show the Congress was how
audio and video can work over a general purpose infrastructure
such as the Internet. Rather than transmit video over the key
transit networks, which tend to get overloaded during events
such as the Internet Town Hall, ARPA had agreed to furnish the
use of DARTNET, the experimental advanced research network they operate.
The underlying transmission facilities for DARTNET are operated
by Sprint. In order for the National Press Club, the headquarters
site for the facility, to be part of DARTNET we required a T1
line from our facility to the Sprint point of presence a few
blocks away. We had requested Sprint to provide that T1 line
and become part of the Internet Town Hall.
In the course of examining our request, Sprint postulated that
furnishing a T1 line for a congressional hearing might violate
congressional ethics laws. There are in fact laws on the books
that prohibit members of Congress or its committees from accepting
in-kind donations over a certain value under certain circumstances.
Sprint forwarded their concerns to the House Ethics Committee,
and then later informed the Subcommittee on Telecommunications
and Finance and my organization of their actions.
Needless to say, there are technical alternatives to the T1 line
that we asked Sprint to furnish. In fact, a single call to
Metropolitan Fiber Systems resulted in a 10 Mbps virtual Ethernet
using ATM between Washington, D.C. and Boston which is available
for the hearing when it does occur.
Even though the technical issue is solved, there still remains
the ethics concern. We firmly believe that a broad industry/government
group volunteering time and money to show how the congressional
process can be changed to include more input from the general
public to be in the public interest. However, we are equally
adamant that *ANY* ethical concerns *MUST* be cleared before
we proceed with the hearings.
The crux of the issue has to do with in-kind contributions. If
you are testifying before Congress, it is clearly allowed to bring
in computers. However, a donation to the underlying infrastructure
of the congressional committee might be construed as an expense
that must be reimbursed by the committee to the donor. The purpose
of such laws is to establish beyond the shadow of a doubt that
the congressional process is clean and not subject to the undue
influence of a particular interest group.
We believe that an on-line congressional hearing is in fact
a desirable thing, particularly given the broad coalition formed
to establish the infrastructure. However, we feel strongly that
everybody involved in the process, whether they are familiar with
the Internet or the law, must understand exactly what we intend
to do and how those actions relate to the ethics laws.
As such, we will spend the next few months describing to congressional
officials exactly what we have in mind for the hearings. Since this
will be a historical occasion, there is no precedent for on-line
hearings. We want to make sure that everybody is very comfortable
with the issues and that officials believe that there is public
benefit in such a demonstration.
I'd like to thank all the volunteers for their time and effort
to date. A tremendous amount of behind the scenes efforts has
already taken place and we're hoping to salvage some of that
effort so we don't have to start from scratch. I'd also like
to thank everybody on the network who sent in letters. The
Subcommittee and Congressman Markey were truly impressed at
the volume and the quality of the commentary from the public
through e-mail and are looking forward to a successful on-line
hearing later in the year.
Sincerely,
Carl Malamud
Internet Multicasting Service
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20978;
7 Jul 93 23:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20972;
7 Jul 93 23:24 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa05178; 7 Jul 93 23:24 EDT
Received: by bitsy.MIT.EDU
id AA10189; Wed, 7 Jul 93 23:15:14 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA10177; Wed, 7 Jul 93 23:15:12 EDT
Received: from mgm.ctt.bellcore.com by MIT.EDU with SMTP
id AA16080; Wed, 7 Jul 93 23:15:10 EDT
Received: from shadow.secure.bellcore.com (shadow-ctt.ctt.bellcore.com) by mgm.ctt.bellcore.com with SMTP id AA06405
(5.65c/IDA-1.4.4 for <cat-ietf at mit.edu>); Wed, 7 Jul 1993 23:15:00 -0400
Received: by shadow.secure.bellcore.com id AA09597
(5.65c/IDA-1.4.4); Wed, 7 Jul 1993 23:14:59 -0400
Date: Wed, 7 Jul 1993 23:14:59 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Lunt <lunt at ctt.bellcore.com>
Message-Id: <199307080314.AA09597 at shadow.secure.bellcore.com>
To: cat-ietf at mit.edu
Subject: NEW FTP Security Extensions draft
Cc: kogut at cc.bellcore.com, ietf-ftpext at ucdavis.edu, jbrown at qdeck.com
CAT WG members,
I just submitted a new revision to the draft to
the Internet Drafts folks. In case it does not get there
in time, you can also get it via anonymous FTP from
thumper.bellcore.com:pub/lunt.
I have not had time to update the code to meet the
new spec. I plan on posting a summary of the diffs since
the last revision to the CAT list sometime before the meeting.
-- Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24674;
8 Jul 93 0:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24668;
8 Jul 93 0:54 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa07288; 8 Jul 93 0:54 EDT
Received: by bitsy.MIT.EDU
id AA11127; Thu, 8 Jul 93 00:35:37 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA11121; Thu, 8 Jul 93 00:35:36 EDT
Received: from mgm.ctt.bellcore.com by MIT.EDU with SMTP
id AA16653; Thu, 8 Jul 93 00:35:34 EDT
Received: from shadow.secure.bellcore.com (shadow-ctt.ctt.bellcore.com) by mgm.ctt.bellcore.com with SMTP id AA06445
(5.65c/IDA-1.4.4 for <cat-ietf at mit.edu>); Thu, 8 Jul 1993 00:35:25 -0400
Received: by shadow.secure.bellcore.com id AA10027
(5.65c/IDA-1.4.4); Thu, 8 Jul 1993 00:35:24 -0400
Date: Thu, 8 Jul 1993 00:35:24 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Lunt <lunt at ctt.bellcore.com>
Message-Id: <199307080435.AA10027 at shadow.secure.bellcore.com>
To: cat-ietf at mit.edu
Subject: Re: NEW FTP Security Extensions draft
Cc: kogut at cc.bellcore.com, ietf-ftpext at ucdavis.edu, jbrown at qdeck.com
CAT WG Members,
Summary of changes to the document as promised.
-- Steve
Summary of changes to the draft since the March IETF meeting:
----------------------------
1. ENC command now is optional
2. GSSAPI specification added
3. Removed erroneous statement: "AUTH command may cause the control
connection to be closed by servers which require the USER
command to be the first command transmitted by the user
after the control connection is made.
4. Clarification that USER command may need to be sent before AUTH
command (to determine required auth type per user, and
some auth types may need to know user name first)
5. Base 64 encoding made the same as in PEM. Made into separate section.
6. Handling proxy file transfers is deferred. Thus, relaxed restriction
that session keys be negotiated, and changed Kerberos
spec accordingly.
7. ADAT exchanges must convey to caller whether encryption is supported
on the security context. Note GSSAPI handles this but Kerberos
V4 spec doesn't.
8. Negotiation of per message protection services left to underlying
token exchange, rather than making explicit provisions
in this protocol. Again, this is in line with GSSAPI.
9. Provision added for server to indicate that all commands must
be encrypted (i.e., that no MIC are accepted).
10. Note to implementors that character set conversion must be
handled on commands and replies before encryption
and after decryption.
11. Provision added for server to indicate that it doesn't support
ENC commands.
12. Default PROTection level no longer changes to Safe after ADAT
succeeds (dues to perception that majority of users and
servers want strong authentication only).
13. Private PROTection level is now optional.
14. Length field (and maximum effective buffer size) on protected
file transfers reduced from 4 bytes (4 Gig max)
to 2 bytes (64 K max) to reduce memory requirements.
Negotiation of maximum deemed too cumbersome.
15. Sender's (cleartext) buffer size is independent of the block size
(in Block mode).
16. Protected file transfers now explicitly (reliably) convey EOF
in Stream mode.
17. Provision added for server to indicate that current PROTection level
not sufficient for file transfer operation.
18. Clarification of when the server may send which protected reply type:
- protected replies if and only if ADAT succeeds
- server decides which of 631/632 to use
- server cannot send 632 replies if the client does not support
encryption
19. Syntactic change to multi-line protected replies for consistency.
Example provided.
20. Made clear that no restriction exists on length of base64 encodings,
and thus server must not reject a command containing a base
64 encoding simply because it is too long. Implementors are
encouraged to realloc until entire command is read.
21. Made it clear that case should not be ignored when reading commands
and replies containing base 64 encodings.
22. Corrected error in BNF for Base 64 encodings.
23. Changed Kerberos V4 server principal name from
"rcmd.host at realm" to "ftp.hostname at realm".
24. Use krb_mk_safe() rather than krb_mk_priv() in protocol
for clients/servers not supporting encryption.
25. No specification under Kerberos Version 5 planned. Instead,
GSSAPI is defined.
26. GSSAPI token exchange expected to negotiate mechanism
rather than making this visible to caller.
27. GSSAPI target principal name: input_name_type=NULL,
input_name_string="SERVICE:ftp at hostname".
Is this general enough?
28. Still need to determine if rcmd principal can be used
in Kerberos V4.
---
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01557;
8 Jul 93 7:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01553;
8 Jul 93 7:22 EDT
Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa04727;
8 Jul 93 7:22 EDT
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-13 #1336) id
<01H0AAO9834G8WWBKS at INNOSOFT.COM>; Thu, 8 Jul 1993 03:45:11 PDT
Received: from haig.cs.ucl.ac.uk by INNOSOFT.COM (PMDF V4.2-13 #1336) id
<01H0AAO0YFGG8WW8W4 at INNOSOFT.COM>; Thu, 8 Jul 1993 03:44:57 PDT
Received: from glengoyne.isode.com by haig.cs.ucl.ac.uk with Internet SMTP id
<g.02514-0 at haig.cs.ucl.ac.uk>; Thu, 8 Jul 1993 11:44:40 +0100
Received: from glengoyne.isode.com by glengoyne.isode.com with SMTP (PP); Thu,
8 Jul 1993 11:44:44 +0100
Date: Thu, 08 Jul 1993 11:44:36 +0100
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Kille <S.Kille at isode.com>
Subject: MADMAN (Mail and Directory Management) WG Agenda
To: ietf-madman at innosoft.com
Cc: ietf at nic.ddn.mil
Errors-to: ned+madman-errors at INNOSOFT.COM
Resent-message-id: <01H0AAO9ARKI8WWBKS at INNOSOFT.COM>
Message-id: <6544.742128276 at isode.com>
X-VMS-To: IN%"ietf-madman at INNOSOFT.COM"
X-VMS-Cc: IN%"ietf at nic.ddn.mil"
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Phone: +44-71-721-7582
Agenda for the MADMAN WG Meeting
Amsterdam IETF
Tuesday 13th July 1993 19:30-22:00
19:30 Introduction
19:35 Minutes of Previous Meeting
19:40 Review "Network Services Monitoring MIB"
20:00 Review "Directory Monitoring MIB"
20:40 Review "Mail Monitoring MIB"
21:45 Review (lack of) progress on Message Store MIB
22:00 Adjourn to Bar
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04995;
8 Jul 93 9:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09478;
8 Jul 93 9:36 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04757;
8 Jul 93 9:35 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04523;
8 Jul 93 9:27 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mhs-ds at mercury.udev.cdc.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-mhsds-supmapping-03.txt, .ps
Date: Thu, 08 Jul 93 09:27:29 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307080927.aa04523 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MHS-DS Working Group of the
IETF.
Title : Use of the Directory to support mapping between X.400
and RFC 822 Addresses
Author(s) : S. Kille
Filename : draft-ietf-mhsds-supmapping-03.txt, .ps
Pages : 7
This document defines how to use directory to support the mapping between
X.400 O/R Addresses and mailboxes defined in RFC 1327.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mhsds-supmapping-03.txt".
Or
"get draft-ietf-mhsds-supmapping-03.ps".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-mhsds-supmapping-03.txt".
Or
"SEND draft-ietf-mhsds-supmapping-03.ps".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-mhsds-supmapping-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mhsds-supmapping-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04993;
8 Jul 93 9:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09476;
8 Jul 93 9:36 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04767;
8 Jul 93 9:35 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04675;
8 Jul 93 9:31 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: frftc at nsco.network.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-frnetmib-fr-01.txt
Date: Thu, 08 Jul 93 09:31:57 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307080931.aa04675 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised 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 : Definitions of Managed Objects for Frame Relay Service
Author(s) : T. Cox Brown
Filename : draft-ietf-frnetmib-fr-01.txt
Pages : 35
This memo defines an extension to the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing the Frame Relay Service.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-frnetmib-fr-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-frnetmib-fr-01.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-frnetmib-fr-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-frnetmib-fr-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04997;
8 Jul 93 9:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09477;
8 Jul 93 9:36 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04764;
8 Jul 93 9:35 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04576;
8 Jul 93 9:28 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: isis at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-isis-nbma-00.txt
Date: Thu, 08 Jul 93 09:28:04 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307080928.aa04576 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the ISIS for IP Internets Working
Group of the IETF.
Title : Routing over Nonbroadcast Multiaccess Links
Author(s) : R. Perlman, C. Gunner
Filename : draft-ietf-isis-nbma-00.txt
Pages : 39
This document assumes basic familiarity with CLNP, ES-IS, IS-IS, ARP, and
IP. The design in this document attempts to minimize routing control
traffic and manual configuration. The issues involve judicious use of CLNP
addressing whenever possible, protocol differentiation (also sometimes
called encapsulation) for coexistence with other protocols running over the
NBMA, enabling ESs to find an active IS, enabling ISs to find each other,
optimizing routes across NBMA (eliminating double-hopping across NBMA), and
efficient and reliable distribution of LSPs (link state packets) across
NBMA.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-isis-nbma-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-isis-nbma-00.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-isis-nbma-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-isis-nbma-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05025;
8 Jul 93 9:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04991;
8 Jul 93 9:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09472;
8 Jul 93 9:36 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04765;
8 Jul 93 9:35 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04551;
8 Jul 93 9:27 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mhs-ds at mercury.udev.cdc.com
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-mhsds-subtrees-03.txt, .ps
Date: Thu, 08 Jul 93 09:27:43 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307080927.aa04551 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MHS-DS Working Group of the
IETF.
Title : Representing Tables and Subtrees in the Directory
Author(s) : S. Kille
Filename : draft-ietf-mhsds-subtrees-03.txt, .ps
Pages : 7
This document defines techniques for representing two types of information
mapping in the OSI Directory.
1. Mapping from a key to a value (or set of values), as might be done in a
table lookup.
2. Mapping from a distinguished name to an associated value (or values),
where the values are not defined by the owner of the entry. This is
achieved by use of a directory subtree.
These techniques were developed for supporting MHS use of Directory,
but are specified separately as they have more general applicability.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mhsds-subtrees-03.txt".
Or
"get draft-ietf-mhsds-subtrees-03.ps".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-mhsds-subtrees-03.txt".
Or
"SEND draft-ietf-mhsds-subtrees-03.ps".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-mhsds-subtrees-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mhsds-subtrees-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05197;
8 Jul 93 9:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05193;
8 Jul 93 9:43 EDT
Received: from mercury91.udev.cdc.com by CNRI.Reston.VA.US id aa09727;
8 Jul 93 9:43 EDT
Received: by mercury.udev.cdc.com; Thu, 8 Jul 93 08:28:46 -0500
X-From: cclark at CNRI.Reston.VA.US Thu Jul 8 08:28 CDT 1993
Received: from ietf.cnri.reston.va.us by mercury.udev.cdc.com id SMTP-0012c3c20fb014884; Thu, 8 Jul 93 08:28:28 -0500
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04513;
8 Jul 93 9:27 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mhs-ds at mercury.udev.cdc.com
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-mhsds-infotree-03.txt, .ps
Date: Thu, 08 Jul 93 09:27:23 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307080927.aa04513 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MHS-DS Working Group of the
IETF.
Title : Representing the O/R Address hierarchy in the Directory
Information Tree
Author(s) : S. Kille
Filename : draft-ietf-mhsds-infotree-03.txt, .ps
Pages : 13
This document defines a representation of the O/R Address hierarchy in the
Directory Information Tree. This is useful for a range of purposes,
including Support for MHS Routing and Support for X.400/RFC 822 address
mappings.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mhsds-infotree-03.txt".
Or
"get draft-ietf-mhsds-infotree-03.ps".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-mhsds-infotree-03.txt".
Or
"SEND draft-ietf-mhsds-infotree-03.ps".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-mhsds-infotree-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mhsds-infotree-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07836;
8 Jul 93 11:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07829;
8 Jul 93 11:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13229;
8 Jul 93 11:29 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07815;
8 Jul 93 11:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07739;
8 Jul 93 11:26 EDT
Received: from bells.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa13167;
8 Jul 93 11:26 EDT
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.29635-0 at bells.cs.ucl.ac.uk>; Thu, 8 Jul 1993 16:26:59 +0100
To: ietf at CNRI.Reston.VA.US
Subject: uk national press...on IPng
Date: Thu, 08 Jul 93 16:26:56 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Message-ID: <9307081126.aa13167 at CNRI.Reston.VA.US>
somewhat lets us down with the following article:
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
