[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
The IESG, being a concentration of power, simply makes the
problem more obvious.
>and that perhaps those of
>us who are trying to do the "best thing for the Internet",
>whether or not we agree on what that is, would be better
>served within an organization that did not have the
>problem of too much navel-gazing about whether or not it
>should actually do anything?
My feeling is that you will run into the *exact* same problem, no
matter what group this sort of activity is done in. The problem is
the Internet is successful, so everybody with their own agendas (you,
me, the IESG members, etc) will attempt to pursue those agendas. As
the group demonstrates it can do something, it will attact more
people, more money, more agendas, and there will inevitably be
conflicts, compromise, and eventually hardening of the arteries.
>More concisely, do you think the IETF is broken enough
>that we shouldn't bother with it any more when it comes to
>policy issues?
Yeah, but given the IETF will likely continue to muck around with
policy issues, I have no particular choice.
As I stated, I have neither the time nor the interest in pursuing the
subject draft within the IETF and have asked to have my name removed
from the author list. I also suspect it unlikely that I will have the
time or interest to get involved in the interminable flame wars that
result any time the IETF gets involved in controversial issues.
However, as I must look out for the best interest of the APNIC members
who pay for my salary, I may at time to time be required to make my
typical rude and pointless statements if I think the IETF is going off
in the weeds again, for whatever that is worth.
>I do. Moreover, I know who I consider to be at fault, and they are
>on your Cc line.
You are both painting with too wide and too narrow a brush. I know a
few members of the IESG and IETF understood the issues regarding the
draft, having followed the discussions and taken the time to
comprehend the situation. They provided valuable input and should the
remaining authors decide it is worthwhile continuing to pursue the
draft, that input should probably be incorporated. However, as I
said, I think the problem is endemic to the entire IETF, so blaming
the IESG (which I assume you meant) would be inappropriate.
Regards,
-drc
Received: from ietf.org by ietf.org id aa07972; 4 Aug 96 15:02 EDT
Received: from cnri by ietf.org id aa07822; 4 Aug 96 14:53 EDT
Received: from mulga.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa08571;
4 Aug 96 14:53 EDT
Received: from mundook.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50)
id AA03611; Mon, 5 Aug 1996 04:52:52 +1000 (from fjh at mundook.cs.mu.OZ.AU)
Received: (from fjh at localhost) by mundook.cs.mu.OZ.AU (8.7.5/8.7.3) id EAA30087; Mon, 5 Aug 1996 04:52:51 +1000 (EST)
Sender:ietf-request at ietf.org
From: Fergus Henderson <fjh at cs.mu.oz.au>
Message-Id: <199608041852.EAA30087 at mundook.cs.mu.OZ.AU>
Subject: Re: spam message from health at moneyworld.com
To: John Curran <jcurran at bbnplanet.com>
Date: Mon, 5 Aug 1996 04:52:51 +1000 (EST)
Cc: mrc at panda.com, ietf at CNRI.Reston.VA.US, spam at zorch.sf-bay.org
In-Reply-To: <v02140b0eae282716a6af at [206.231.68.12]> from "John Curran" at Aug 2, 96 06:03:36 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
John Curran wrote:
>
> We don't terminate without process. We've been working on this
> site (which is the customer of a BBN Planet business partner) since
> early July, but folks are going to have to be patient for another few
> weeks due to notice requirements.
I'm all in favour of due process, but let me make one thing clear: any
policy which requires us to "be patient for another few weeks" despite
clear prima facie evidence of spam originating from a particular site is
absolutely totally unacceptable.
--
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3 | -- the last words of T. S. Garp.
Received: from ietf.org by ietf.org id aa24313; 5 Aug 96 8:45 EDT
Received: from cnri by ietf.org id aa24309; 5 Aug 96 8:45 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06039;
5 Aug 96 8:45 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <MAA12183 at pad-thai.cam.ov.com>; Mon, 5 Aug 1996 12:02:35 GMT
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA02057; Mon, 5 Aug 96 08:02:34 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <MAA12179 at pad-thai.cam.ov.com>; Mon, 5 Aug 1996 12:02:19 GMT
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id IAA18390; Mon, 5 Aug 1996 08:02:17 -0400
Message-Id: <199608051202.IAA18390 at winkl.cam.ov.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: IESG requests and proposed responses re GSS-V2 document
Date: Mon, 05 Aug 1996 08:02:17 -0400
Sender:ietf-archive-request at ietf.org
From: John Linn <linn at cam.ov.com>
CAT/GSS-V2 fanciers:
Jeff Schiller informed me last week that, in the course of reviewing
GSS-V2 for advancement to Proposed Standard, the IESG requested two
additions to the document (though no changes to existing text). This
message presents my proposed responses; to enable an updated version
to be posted and reballoted at the IESG level later this month, I'll
request that any WG comments on these be posted to the list no later
than Wednesday, 14 August.
(1) The first request is extremely simple to accomodate: to everyone's
surprise and through editorial oversight, draft-ietf-cat-gssv2-06.txt
failed to include the required "Security Considerations" section! I
believe that it's reasonable and appropriate to respond, for the case
of this document, by restoring the single-sentence section: "Security
considerations are discussed throughout this memo.", as was present
in RFC-1508.
(2) The second request requires more extensive effort and response,
but I believe achieves a corresponding valuable result. This IESG
request was for an appendix summarizing the changes from GSS-V1 to
GSS-V2, and compatibility issues between the versions. My draft for a
new Appendix B is attached.
Regards, ...
--jl
------draft compatibility appendix follows, cut here-----
APPENDIX B
COMPATIBILITY WITH GSS-V1
It is the intent of this document to define an interface and procedures
which preserve compatibility between GSS-V1 (RFC-1508) callers and GSS-
V2 providers. All calls defined in GSS-V1 are preserved, and it has
been a goal that GSS-V1 callers should be able to operate atop GSS-V2
provider implementations. Certain detailed changes, summarized in this
section, have been made in order to resolve omissions identified in
GSS-V1.
The following GSS-V1 constructs, while supported within GSS-V2, are
deprecated:
Names for per-message processing routines: GSS_Seal() deprecated in
favor of GSS_Wrap(); GSS_Sign() deprecated in favor of
GSS_GetMIC(); GSS_Unseal() deprecated in favor of GSS_Unwrap();
GSS_Verify() deprecated in favor of GSS_VerifyMIC().
GSS_Delete_sec_context() facility for context_token usage, allowing
mechanisms to signal context deletion, is retained for
compatibility with GSS-V1. For current usage, it is recommended
that both peers to a context invoke GSS_Delete_sec_context()
independently, passing a null output_context_token buffer to
indicate that no context_token is required. Implementations of
GSS_Delete_sec_context() should delete relevant locally-stored
context information.
This GSS-V2 specification adds the following calls which are not present
in GSS-V1:
Credential management calls: GSS_Add_cred(),
GSS_Inquire_cred_by_mech().
Context-level calls: GSS_Inquire_context(), GSS_Wrap_size_limit(),
GSS_Export_sec_context(), GSS_Import_sec_context().
Per-message calls: No new calls. Existing calls have been renamed.
Support calls: GSS_Create_empty_OID_set(),
GSS_Add_OID_set_member(), GSS_Test_oid_set_member(),
GSS_Release_OID(), GSS_OID_to_str(), GSS_Str_to_OID(),
GSS_Inquire_names_for_mech(), GSS_Inquire_mechs_for_name(),
GSS_Canonicalize_name(), GSS_Export_name(), GSS_Duplicate_name().
This GSS-V2 specification introduces three new facilities applicable to
security contexts, indicated using the following context state values
which are not present in GSS-V1:
anon_state, set TRUE to indicate that a context's initiator is
anonymous from the viewpoint of the target; Section 1.2.5 of this
specification provides a summary description of the GSS-V2
anonymity support facility, support and use of which is optional.
prot_ready_state, set TRUE to indicate that a context may be used
for per-message protection before final completion of context
establishment; Section 1.2.7 of this specification provides a
summary description of the GSS-V2 facility enabling mechanisms to
selectively permit per-message protection during context
establishment, support and use of which is optional.
trans_state, set TRUE to indicate that a context is transferable to
another process using the GSS-V2 GSS_Export_sec_context() facility.
These state values are represented (at the C bindings level) in
positions within a bit vector which are unused in GSS-V1, and may be
safely ignored by GSS-V1 callers.
Relative to GSS-V1, GSS-V2 provides additional guidance to GSS-API
implementors in the following areas: implementation robustness,
credential management, behavior in multi-mechanism configurations,
naming support, and inclusion of optional sequencing services. The
token tagging facility as defined in GSS-V2, Section 3.1, is now
described directly in terms of octets to facilitate interoperable
implementation without general ASN.1 processing code; the corresponding
ASN.1 syntax, included for descriptive purposes, is unchanged from that
in GSS-V1. For use in conjunction with added naming support facilities,
a new Exported Name Object construct is added. Additional name types
are introduced in Section 4.
This GSS-V2 specification adds the following major_status values which
are not defined in GSS-V1:
GSS_S_BAD_QOP unsupported QOP value
GSS_S_UNAUTHORIZED operation unauthorized
GSS_S_UNAVAILABLE operation unavailable
GSS_S_DUPLICATE_ELEMENT duplicate credential element requested
GSS_S_NAME_NOT_MN name contains multi-mechanism elements
GSS_S_GAP_TOKEN skipped predecessor token(s)
detected
Of these added status codes, only two values are defined to be
returnable by calls existing in GSS-V1: GSS_S_BAD_QOP (returnable by
GSS_GetMIC() and GSS_Wrap()), and GSS_S_GAP_TOKEN (returnable by
GSS_VerifyMIC() and GSS_Unwrap()).
Additionally, GSS-V2 descriptions of certain calls present in GSS-V1
have been updated to allow return of additional major_status values from
the set as defined in GSS-V1: GSS_Inquire_cred() has
GSS_S_DEFECTIVE_CREDENTIAL and GSS_S_CREDENTIALS_EXPIRED defined as
returnable, GSS_Init_sec_context() has GSS_S_OLD_TOKEN,
GSS_S_DUPLICATE_TOKEN, and GSS_S_BAD_MECH defined as returnable, and
GSS_Accept_sec_context() has GSS_S_BAD_MECH defined as returnable.
Received: from ietf.org by ietf.org id aa24847; 5 Aug 96 9:48 EDT
Received: from cnri by ietf.org id aa24843; 5 Aug 96 9:48 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06963;
5 Aug 96 9:48 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <NAA15223 at pad-thai.cam.ov.com>; Mon, 5 Aug 1996 13:13:05 GMT
Received: from mail13.digital.com by MIT.EDU with SMTP
id AA11704; Mon, 5 Aug 96 09:13:03 EDT
Received: from us1rmc.bb.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV)
id JAA30031; Mon, 5 Aug 1996 09:09:17 -0400 (EDT)
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA24419; Mon, 5 Aug 96 09:10:17 -0400
Message-Id: <9608051310.AA24419 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Mon, 5 Aug 96 09:10:17 EDT
Date: Mon, 5 Aug 96 09:10:17 EDT
Sender:ietf-archive-request at ietf.org
From: "John Wray, Digital DPE, (508) 486-5210 05-Aug-1996 0907" <wray at tuxedo.enet.dec.com>
To: "cat-ietf at mit.edu"@in.enet.dec.com
Cc: wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu
Subject: GSSAPI V2 C-bindings
I have (at last) submitted an updated C-bindings draft for V2 of the GSSAPI.
It should appear on the archive sites within a few days.
John
Received: from ietf.org by ietf.org id aa02739; 5 Aug 96 11:32 EDT
Received: from localhost by ietf.org id aa01672; 5 Aug 96 11:12 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipsec at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-skip-udh-01.txt
Date: Mon, 05 Aug 1996 11:12:50 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9608051112.aa01672 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : Encoding of an Unsigned Diffie-Hellman Public Value
Author(s) : A. Aziz, T. Markson, H. Prafullchandra
Filename : draft-ietf-ipsec-skip-udh-01.txt
Pages : 6
Date : 08/02/1996
It is useful to be able to communicate public keys in the absence of a
certificate hierarchy and a signature infrastructure. This document
describes a method by which certificates which communicate Diffie-Hellman
public values and parameters may be encoded and securely named.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-skip-udh-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-udh-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-skip-udh-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960805101155.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-skip-udh-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-skip-udh-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960805101155.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02740; 5 Aug 96 11:32 EDT
Received: from localhost by ietf.org id aa01566; 5 Aug 96 11:11 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: atommib at thumper.bellcore.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-atommib-acct-03.txt
Date: Mon, 05 Aug 1996 11:11:15 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9608051111.aa01566 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the AToM MIB Working Group of
the IETF.
Title : Managed Objects for Controlling the Collection and
Storage of Accounting Information for
Connection-Oriented Networks
Author(s) : K. McCloghrie, J. Heinanen, W. Greene, A. Prasad
Filename : draft-ietf-atommib-acct-03.txt
Pages : 28
Date : 08/02/1996
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
controlling the collection and storage of accounting information for
connection-oriented networks such as ATM. The accounting data is collected
into files for later retrieval via a file transfer protocol. For
information on data which can be collected for ATM networks, see [9].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-atommib-acct-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-acct-03.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-atommib-acct-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960805101034.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-atommib-acct-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-atommib-acct-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960805101034.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02735; 5 Aug 96 11:32 EDT
Received: from localhost by ietf.org id aa01628; 5 Aug 96 11:12 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: atommib at thumper.bellcore.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-atommib-atmacct-00.txt
Date: Mon, 05 Aug 1996 11:12:25 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9608051112.aa01628 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the AToM MIB Working Group of
the IETF.
Title : Accounting Information for ATM Networks
Author(s) : K. McCloghrie, J. Heinanen, W. Greene, A. Prasad
Filename : draft-ietf-atommib-atmacct-00.txt
Pages : 14
Date : 08/02/1996
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. A separate memo [8] defines managed objects, in a manner
independent of the type of network, for controlling the selection,
collection and storage of accounting information into files for later
retrieval via a file transfer protocol. This memo defines a set of
ATM-specific accounting information which can be collected for connections
on ATM networks.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-atommib-atmacct-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-atmacct-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-atommib-atmacct-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960805101058.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-atommib-atmacct-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-atommib-atmacct-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960805101058.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02734; 5 Aug 96 11:32 EDT
Received: from localhost by ietf.org id aa01650; 5 Aug 96 11:12 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dns-security at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dnssec-secext-10.txt
Date: Mon, 05 Aug 1996 11:12:38 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9608051112.aa01650 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Domain Name System Security
Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : Domain Name System Security Extensions
Author(s) : D. Eastlake, C. Kaufman
Filename : draft-ietf-dnssec-secext-10.txt
Pages : 45
Date : 08/02/1996
The Domain Name System (DNS) has become a critical operational part of the
Internet infrastructure yet it has no strong security mechanisms to assure
data integrity or authentication. Extensions to the DNS are described that
provide these services to security aware resolvers or applications through
the use of cryptographic digital signatures. These digital signatures are
included in secured zones as resource records. Security can still be
provided even through non-security aware DNS servers in many cases.
The extensions also provide for the storage of authenticated public keys in
the DNS. This storage of keys can support general public key distribution
service as well as DNS security. The stored keys enable security aware
resolvers to learn the authenticating key of zones in addition to those for
which they are initially configured. Keys associated with DNS names can be
retrieved to support other protocols. Provision is made for a variety of
key types and algorithms. In addition, the security extensions provide
for the optional authentication of DNS protocol transactions.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dnssec-secext-10.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-10.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dnssec-secext-10.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960805101146.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnssec-secext-10.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnssec-secext-10.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960805101146.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04282; 5 Aug 96 11:52 EDT
Received: from localhost by ietf.org id aa03714; 5 Aug 96 11:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipsec at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-skip-udh-01.txt
Date: Mon, 05 Aug 1996 11:49:28 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608051149.aa03714 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : Encoding of an Unsigned Diffie-Hellman Public Value
Author(s) : A. Aziz, T. Markson, H. Prafullchandra
Filename : draft-ietf-ipsec-skip-udh-01.txt
Pages : 6
Date : 08/02/1996
It is useful to be able to communicate public keys in the absence of a
certificate hierarchy and a signature infrastructure. This document
describes a method by which certificates which communicate Diffie-Hellman
public values and parameters may be encoded and securely named.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-skip-udh-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-udh-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-skip-udh-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960802103034.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-skip-udh-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-skip-udh-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960802103034.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04280; 5 Aug 96 11:52 EDT
Received: from localhost by ietf.org id aa03648; 5 Aug 96 11:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-waters-reduce-isdn-costs-01.txt
Date: Mon, 05 Aug 1996 11:49:05 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608051149.aa03648 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Reducing the ISDN costs of Network Applications
that use TCP/IP.
Author(s) : S. Waters
Filename : draft-waters-reduce-isdn-costs-01.txt
Pages : 11
Date : 08/02/1996
This document discusses TCP/IP traffic on ISDN links and makes
recommendations to Network Application and Router developers with a view to
reducing the cost of using ISDN.
This topic is partly related to current activity in the PPP Working Group
on controls for Protocol Spoofing, but mainly targets the developers of
Network software such as Resource Sharing protocols, for example Network
Service and Directory Sharing.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-waters-reduce-isdn-costs-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-waters-reduce-isdn-costs-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-waters-reduce-isdn-costs-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960802095839.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-waters-reduce-isdn-costs-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-waters-reduce-isdn-costs-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960802095839.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04284; 5 Aug 96 11:52 EDT
Received: from localhost by ietf.org id aa03664; 5 Aug 96 11:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: atommib at thumper.bellcore.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-atommib-atmacct-00.txt
Date: Mon, 05 Aug 1996 11:49:10 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608051149.aa03664 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the AToM MIB Working Group of
the IETF.
Title : Accounting Information for ATM Networks
Author(s) : K. McCloghrie, J. Heinanen, W. Greene, A. Prasad
Filename : draft-ietf-atommib-atmacct-00.txt
Pages : 14
Date : 08/02/1996
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. A separate memo [8] defines managed objects, in a manner
independent of the type of network, for controlling the selection,
collection and storage of accounting information into files for later
retrieval via a file transfer protocol. This memo defines a set of
ATM-specific accounting information which can be collected for connections
on ATM networks.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-atommib-atmacct-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-atmacct-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-atommib-atmacct-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960802154707.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-atommib-atmacct-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-atommib-atmacct-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960802154707.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04307; 5 Aug 96 11:52 EDT
Received: from ietf.org by ietf.org id aa04278; 5 Aug 96 11:52 EDT
Received: from localhost by ietf.org id aa03680; 5 Aug 96 11:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: atommib at thumper.bellcore.com
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-atommib-acct-03.txt
Date: Mon, 05 Aug 1996 11:49:13 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608051149.aa03680 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the AToM MIB Working Group of
the IETF.
Title : Managed Objects for Controlling the Collection and
Storage of Accounting Information for
Connection-Oriented Networks
Author(s) : K. McCloghrie, J. Heinanen, W. Greene, A. Prasad
Filename : draft-ietf-atommib-acct-03.txt
Pages : 28
Date : 08/02/1996
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
controlling the collection and storage of accounting information for
connection-oriented networks such as ATM. The accounting data is collected
into files for later retrieval via a file transfer protocol. For
information on data which can be collected for ATM networks, see [9].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-atommib-acct-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-acct-03.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-atommib-acct-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960802103606.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-atommib-acct-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-atommib-acct-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960802103606.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05116; 5 Aug 96 12:20 EDT
Received: from localhost by ietf.org id aa03738; 5 Aug 96 11:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dns-security at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dnssec-secext-10.txt
Date: Mon, 05 Aug 1996 11:49:33 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608051149.aa03738 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Domain Name System Security
Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : Domain Name System Security Extensions
Author(s) : D. Eastlake, C. Kaufman
Filename : draft-ietf-dnssec-secext-10.txt
Pages : 45
Date : 08/02/1996
The Domain Name System (DNS) has become a critical operational part of the
Internet infrastructure yet it has no strong security mechanisms to assure
data integrity or authentication. Extensions to the DNS are described that
provide these services to security aware resolvers or applications through
the use of cryptographic digital signatures. These digital signatures are
included in secured zones as resource records. Security can still be
provided even through non-security aware DNS servers in many cases.
The extensions also provide for the storage of authenticated public keys in
the DNS. This storage of keys can support general public key distribution
service as well as DNS security. The stored keys enable security aware
resolvers to learn the authenticating key of zones in addition to those for
which they are initially configured. Keys associated with DNS names can be
retrieved to support other protocols. Provision is made for a variety of
key types and algorithms.
In addition, the security extensions provide for the optional
authentication of DNS protocol transactions.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dnssec-secext-10.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-10.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dnssec-secext-10.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960802160759.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnssec-secext-10.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnssec-secext-10.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960802160759.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17050; 5 Aug 96 18:58 EDT
Received: from cnri by ietf.org id aa17046; 5 Aug 96 18:58 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17983;
5 Aug 96 18:58 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <WAA11476 at pad-thai.cam.ov.com>; Mon, 5 Aug 1996 22:26:04 GMT
Received: from tcsi.com by MIT.EDU with SMTP
id AA25961; Mon, 5 Aug 96 18:25:37 EDT
Received: from keymaster.tcs.com (keymaster.tcs.com [137.134.63.4]) by gateway.tcsi.com (8.7.4/8.7.3) with ESMTP id PAA14253 for <cat-ietf at mit.edu>; Mon, 5 Aug 1996 15:25:26 -0700 (PDT)
Received: from carman.tcs.com (carman.tcs.com [137.134.79.84]) by keymaster.tcs.com (8.7.5/8.7.3) with SMTP id PAA10092 for <cat-ietf at mit.edu>; Mon, 5 Aug 1996 15:27:55 -0700 (PDT)
Received: by carman.tcs.com (5.x/SMI-SVR4)
id AA02322; Mon, 5 Aug 1996 15:24:37 -0700
Date: Mon, 5 Aug 1996 15:24:37 -0700
Sender:ietf-archive-request at ietf.org
From: Alexander Aizman <alexa at tcsi.com>
Message-Id: <9608052224.AA02322 at carman.tcs.com>
To: cat-ietf at mit.edu
Subject: XGSS-API
X-Sun-Charset: US-ASCII
Hello,
What is the status of XGSS-API (in a process of becoming standard,
completely forgotten, etc)?
I'm asking because I think of implementing CORBA security, and GSS-API
seems to be appropriate, but XGSS even better.
But I'm not seeing mentioning of XGSS on relevant mailing lists.
Alex Aizman,
alexa at tcsi.com
Received: from ietf.org by ietf.org id aa20853; 5 Aug 96 22:52 EDT
Received: from cnri by ietf.org id aa20839; 5 Aug 96 22:52 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20638;
5 Aug 96 22:52 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <CAA22194 at pad-thai.cam.ov.com>; Tue, 6 Aug 1996 02:26:25 GMT
Received: from megamegs.decisive.com by MIT.EDU with SMTP
id AA11185; Mon, 5 Aug 96 22:26:12 EDT
Received: from jamie.decisive.com ([206.171.43.189])
by megamegs.decisive.com (post.office MTA v1.9.3 ID# 0-12889)
with SMTP id AAA160 for <cat-ietf at MIT.EDU>;
Mon, 5 Aug 1996 18:42:14 -0700
Received: by jamie.decisive.com with Microsoft Mail
id <01BB8304.27097660 at jamie.decisive.com>; Mon, 5 Aug 1996 19:27:34 -0700
Message-Id: <01BB8304.27097660 at jamie.decisive.com>
Sender:ietf-archive-request at ietf.org
From: Network Education Center <feedback at decisive.com>
To: "'cat-ietf at MIT.EDU'" <cat-ietf at mit.edu>
Subject: Survey on Continuing Education for Network Computing Professionals
Date: Mon, 5 Aug 1996 18:28:03 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
This survey is on behalf of an education center dedicated to the needs =
of network computing professionals. We are asking your input to help us =
create better education/training programs for you and your company. Your =
responses will be completely confidential.
If we receive your completed survey by Monday, August 12, 1996, we'll =
automatically enter you in a contest for a prize of $1,000; one winner =
will be chosen from among those who complete the survey. Thank you in =
advance for your help.=20
(Authentication marker -- ~3%e%INTCADX%8%1%257%5CTJVlfE%38614& -- do not =
remove.)=20
To respond, create a reply e-mail message that contains the survey. =
Some e-mail systems require you to manually copy and paste the survey =
into your reply. Make sure the reply contains the *entire* =
authentication marker, including what looks like garbage.
To answer a question, type an x between the brackets, like this: [ x ]. =
For fill-in-the-blanks, type between the brackets like this: [ your =
response ]. Please make no other changes to this survey.
1. If for any reason you do NOT want to be contacted in the future via =
e-mail, please indicate after the first question by placing an "x" =
within the brackets. You will be omitted from future e-mail surveys.
[ ] a) Please omit me from future e-mail surveys.
2. What is your company's PRIMARY industry or business?
Choose one:
[ ] a) Aerospace
[ ] b) Communications carrier (telco, broadband, internet)
[ ] c) Financial services
[ ] d) Healthcare
[ ] e) Manufacturing: computer/software
[ ] f) Manufacturing: non-computer
[ ] g) Government/military
[ ] h) Publishing/media/advertising/public relations
[ ] i) Transportation/utilities
[ ] j) Wholesale/retail: non-computer
[ ] k) Education
[ ] l) Entertainment
[ ] m) Computer reseller/retailer/VAR
[ ] n) Systems integration/consulting
[ ] o) Other, please specify... [ ]
3. What is your job function?
Choose one:
[ ] a) IS/MIS/Data processing
[ ] b) LAN/network systems
[ ] c) Internet/Web
[ ] d) Intranet (in-TRA-net)
[ ] e) Data communications/telecommunications
[ ] f) PC/microcomputer/information center
[ ] g) Systems analyst/applications development
[ ] h) Systems engineer/integration
[ ] i) Other computer-related, please specify... [ ]
[ ] j) Executive/corporate office
[ ] k) Financial/accounting
[ ] l) Engineering/R&D
[ ] m) Sales/marketing
[ ] n) Other administrative, please specify... [ ]
[ ] o) Consulting (computer related)
[ ] p) Training/education
[ ] q) Other professional, please specify... [ ]
4. Please check the statements below that describe your involvement =
with networks.
Choose all that apply:
[ ] a) I manage networks.
[ ] b) I design networks.
[ ] c) I install networks.
[ ] d) I troubleshoot/fix networks.
[ ] e) I train or support network users.
[ ] f) I initiate the evaluation of new network technologies.
[ ] g) I evaluate or specify brands of network products.
[ ] h) I ensure that networks meet specific business or =
organizational objectives.
5. What is the scope of your involvement with networking in your =
organization?
Choose one:
[ ] a) Entire organization or enterprise
[ ] b) Entire work location
[ ] c) Multiple departments at more than one location
[ ] d) For a single department only
[ ] e) Other
6. How many servers do you have installed in your organization?
Choose one:
[ ] a) Over 50
[ ] b) 10 to 49
[ ] c) 1 to 9
[ ] d) None
7. How many LANS do you have installed in your organization?
Choose one:
[ ] a) Over 25
[ ] b) 5 to 24
[ ] c) 1 to 4
[ ] d) None
8. How many microcomputers/workstations are connected to LANS in your =
organization?
Choose one:
[ ] a) 500 or more
[ ] b) 25 to 499
[ ] c) 1 to 24
[ ] d) None
9. How many employees do you supervise?
Choose one:
[ ] a) Up to 3 people
[ ] b) 4 to 10 people
[ ] c) More than 10 people
[ ] d) None
10. Do you yourself have responsibility for networking =
education/training provided to employees in your company?
Choose one:
[ ] a) Yes
[ ] b) No
[ ] c) Don't know
11. What is the annual budget for education/training for yourself and =
those you supervise?
Please enter the amount within the following brackets. [ ]
12. During the last 12 months, where did you or those you supervise =
receive education/training for networking?
Choose all that apply:
[ ] a) In-house
[ ] b) University/college
[ ] c) Seminars
[ ] d) Internet
[ ] e) Other
[ ] f) No education/training on networking was received
NOW WE WANT YOUR OPINIONS ABOUT A POSSIBLE EDUCATION CURRICULUM ON =
NETWORKING TECHNOLOGIES. For each of the following 10 course =
descriptions, please indicate your level of interest.
13. A Network Technologies course covering circuits and fibers; =
modulation and modems; LANs; WANs; frames; cell switching; wireless; =
satellites; connection-oriented and connectionless service; =
characteristics of each technology; addressing; media access; =
comparisons.
Choose one:
[ ] a) Very interesting
[ ] b) Moderately interesting
[ ] c) Somewhat interesting
[ ] d) Not at all interesting
14. A Network Interconnection and Internetworking course covering =
interconnection technologies; repeaters, bridges, and routers; internet =
addressing; address binding; datagram forwarding; techniques to =
accomodate heterogeneity (e.g. encapsulation and fragmentation).
Choose one:
[ ] a) Very interesting
[ ] b) Moderately interesting
[ ] c) Somewhat interesting
[ ] d) Not at all interesting
15. A Network Protocols and Protocol Design course covering protocol =
layering; problems protocols solve; loss, reordering, corruption, =
congestion, duplication, and replay; techniques such as framing, =
checksumming, sliding window, and retransmission; focus on the transport =
layer, but cover other layers.
Choose one:
[ ] a) Very interesting
[ ] b) Moderately interesting
[ ] c) Somewhat interesting
[ ] d) Not at all interesting
16. A Routing and Routing Protocols course covering packet forwarding; =
route propagation; vector-distance and link-state algorithms; spanning =
tree.
Choose one:
[ ] a) Very interesting
[ ] b) Moderately interesting
[ ] c) Somewhat interesting
[ ] d) Not at all interesting
17. A Distributed Programming and Applications course covering =
client-server paradigm; socket API; middleware (e.g. RPC and CORBA); =
building a server; multithread server execution; protection and =
authorization; example applications.
Choose one:
[ ] a) Very interesting
[ ] b) Moderately interesting
[ ] c) Somewhat interesting
[ ] d) Not at all interesting
18. A Network and Protocol Performance Evaluation course covering =
throughput and delay; measuring and tuning protocols; instrumentation of =
protocol stacks; traffic analysis; self-similar behavior.
Choose one:
[ ] a) Very interesting
[ ] b) Moderately interesting
[ ] c) Somewhat interesting
[ ] d) Not at all interesting
19. A Networking and Protocol Support for Multimedia Applications =
course covering high-speed networks; resource allocation and performance =
guarantees; protocols for audio and video; techniques such as =
compression and delayed playback.
Choose one:
[ ] a) Very interesting
[ ] b) Moderately interesting
[ ] c) Somewhat interesting
[ ] d) Not at all interesting
20. An Advanced Server Design and Implementation course covering =
implementation of concurrent, parallel servers; large-scale designs; =
proxy servers (e.g., SLIRP); techniques such as buffering, replication, =
caching, and application gateways.
Choose one:
[ ] a) Very interesting
[ ] b) Moderately interesting
[ ] c) Somewhat interesting
[ ] d) Not at all interesting
21. An Advanced Routing course covering policy-based routing; =
multicast; mobility; inter- and intra-layer encapsulation; longest =
prefix forwarding table lookup algorithms; virtual LANS.
Choose one:
[ ] a) Very interesting
[ ] b) Moderately interesting
[ ] c) Somewhat interesting
[ ] d) Not at all interesting
22. An Advanced Network Applications course covering EDI; electronic =
commerce; advanced Web techniques (e.g. Java).
Choose one:
[ ] a) Very interesting
[ ] b) Moderately interesting
[ ] c) Somewhat interesting
[ ] d) Not at all interesting
23. What would your level of interest be in taking a group of these =
courses as a coordinated curriculum?
Choose one:
[ ] a) Very interesting
[ ] b) Moderately interesting
[ ] c) Somewhat interesting
[ ] d) Not at all interesting
THINKING ABOUT THE CHARACTERISTICS AND BENEFITS OF DIFFERENT TYPES OF =
EDUCATION PROGRAMS that could be made available for networking =
technologies, please indicate which of the following would be important =
to you.
24. A course curriculum leads to an advanced college degree.
Choose one:
[ ] a) Very important
[ ] b) Somewhat important
[ ] c) Not very important
[ ] d) Not at all important
[ ] e) No opinion
25. Each course generates a document of professional certification.
Choose one:
[ ] a) Very important
[ ] b) Somewhat important
[ ] c) Not very important
[ ] d) Not at all important
[ ] e) No opinion
26. Course curriculum leads to an overall certification.
Choose one:
[ ] a) Very important
[ ] b) Somewhat important
[ ] c) Not very important
[ ] d) Not at all important
[ ] e) No opinion
27. Course is available at your place of work.
Choose one:
[ ] a) Very important
[ ] b) Somewhat important
[ ] c) Not very important
[ ] d) Not at all important
[ ] e) No opinion
28. Course is available at a local university or college campus.
Choose one:
[ ] a) Very important
[ ] b) Somewhat important
[ ] c) Not very important
[ ] d) Not at all important
[ ] e) No opinion
29. Courses available at an industry event you already attend.
Choose one:
[ ] a) Very important
[ ] b) Somewhat important
[ ] c) Not very important
[ ] d) Not at all important
[ ] e) No opinion
30. Courses conducted by an advanced educational institute staffed by =
networking experts.
Choose one:
[ ] a) Very important
[ ] b) Somewhat important
[ ] c) Not very important
[ ] d) Not at all important
[ ] e) No opinion
31. A core curriculum of a specified number of courses that would =
follow a building educational sequence.
Choose one:
[ ] a) Very important
[ ] b) Somewhat important
[ ] c) Not very important
[ ] d) Not at all important
[ ] e) No opinion
32. A concentrated face-to-face education program conducted over =
consecutive days.
Choose one:
[ ] a) Very important
[ ] b) Somewhat important
[ ] c) Not very important
[ ] d) Not at all important
[ ] e) No opinion
33. Ability to take class lessons, labs and tests over the Internet =
from your desktop.
Choose one:
[ ] a) Very important
[ ] b) Somewhat important
[ ] c) Not very important
[ ] d) Not at all important
[ ] e) No opinion
34. What other thoughts do you have concerning what could be done to =
improve educational or training programs on networking technologies?
Please write within the brackets. [ ]
35. How many years have you been professionally involved in computing?
Choose one:
[ ] a) Less than 2 years
[ ] b) 2 to 4 years
[ ] c) 5 to 10 years
[ ] d) More than 10 years
36. Which of the following ranges includes your age?
Choose one:
[ ] a) 18 to 34
[ ] b) 35 to 44
[ ] c) 45 to 54
[ ] d) 55 and older
37. Which of the following represents your highest level of education?
Choose one:
[ ] a) Attended high school
[ ] b) Graduated high school
[ ] c) Attended college
[ ] d) Bachelor's degree
[ ] e) Master's degree
[ ] f) Doctorate degree
38. What do you estimate your total household income was last year? =
(Please estimate total income for everyone in your household, including =
salaries, wages, bonuses, interest, dividends, etc.)
Choose one:
[ ] a) Less than $15,000
[ ] b) $15,000 to $24,999
[ ] c) $25,000 to $34,999
[ ] d) $35,000 to $49,999
[ ] e) $50,000 to $74,999
[ ] f) $75,000 to $99,999
[ ] g) $100,000 to $149,999
[ ] h) $150,000 or more
[ ] i) Don't know
Thank you for participating in this survey.
Received: from ietf.org by ietf.org id aa02268; 6 Aug 96 4:40 EDT
Received: from cnri by ietf.org id aa02264; 6 Aug 96 4:40 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa03751;
6 Aug 96 4:40 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <IAA02983 at pad-thai.cam.ov.com>; Tue, 6 Aug 1996 08:06:20 GMT
Received: from rdsita.ed.nce.sita.int by MIT.EDU with SMTP
id AA24099; Tue, 6 Aug 96 04:06:09 EDT
Received: from 57.4.25.1.rdsita-fr by rdsita.ed.nce.sita.int (8.6.12/SitaNet-1.4)
id KAA06631; Tue, 6 Aug 1996 10:05:15 +0200
Message-Id: <32077BC0.76D6 at ed.nce.sita.int>
Date: Tue, 06 Aug 1996 10:07:12 -0700
Sender:ietf-archive-request at ietf.org
From: Steen Larsen <Steen.Larsen at ed.nce.sita.int>
Organization: SITA
X-Mailer: Mozilla 2.0 (Win95; I; 16bit)
Mime-Version: 1.0
To: Alexander Aizman <alexa at tcsi.com>
Cc: cat-ietf at mit.edu
Subject: Re: XGSS-API
References: <9608052224.AA02322 at carman.tcs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Alexander Aizman wrote:
>
> Hello,
>
> What is the status of XGSS-API (in a process of becoming standard,
> completely forgotten, etc)?Definitely not forgotten, I suggest that you take a look at this Internet draft:
draft-ietf-cat-xgssapi-acc-cntrl-01.txt
Extended Generic Security Service APIs: XGSS-APIs Access control
and delegation extensions
Tom Parker, ICL; Denis Pinkas, Bull, July 5, 1996
Expires: January 5, 1997
Pages: 23
You should also take a look at the this URL (It also contains a reference
to the above):
http://www.ietf.cnri.reston.va.us/html.charters/cat-charter.html
Common Authentication Technology (cat) Charter
> I'm asking because I think of implementing CORBA security, and GSS-API
> seems to be appropriate, but XGSS even better.Regarding CORBA and GSS-API I found this some time ago
http://www.omg.org/archives/interop/0251.html
secure IOR
April Chang (April.Chang at Eng.Sun.COM)
Mon, 20 Nov 1995 16:12:26 -0800
Best regards
--
Steen Koefoed Larsen <steen.larsen at ed.nce.sita.int>
Disclaimer: This letter may contain pure garbage that differs
from the opinion of myself and the companies I work for.
SITA -- Societe Internationale de Telecommunications Aeronautiqes
R & D Nice, Heraklion - 1041 Route des Dolines, F-06560 Valbonne
Phone: +33 92.96.63.67, Fax: +33 92.96.64.92, SITATEX: NCEEMXS
E-mail at home: steenkl at dircon.co.uk, GSM Mobile: +45 40512486
*** Syntax? Why not - they tax everything else! ***
Received: from ietf.org by ietf.org id aa05416; 6 Aug 96 9:32 EDT
Received: from localhost by ietf.org id aa04319; 6 Aug 96 9:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-bradner-access-control-02.txt
Date: Tue, 06 Aug 1996 09:18:44 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608060918.aa04319 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Source directed access control on the Internet.
Author(s) : S. Bradner
Filename : draft-bradner-access-control-02.txt
Pages : 19
Date : 08/05/1996
This Internet Draft was developed from a deposition that I submitted as
part of a challenge to the Communications Decency Act of 1996, part of the
Telecommunications Reform Act of 1996. The Telecommunications Reform Act
is a U.S. federal law substantially changing the regulatory structure in
the United States in the telecommunications arena. The Communications
Decency Act (CDA) part of this law has as its aim the desire to protect
minors from some of the material carried over telecommunications networks.
In particular the law requires that the sender of potentially offensive
material take "effective action" to ensure that it is not presented to
minors. A number of people have requested that I publish the deposition as
an informational RFC since some of the information in it may be useful
where descriptions of the way the Internet and its applications work could
help clear up confusion in the technical feasibility of proposed content
control regulations.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-bradner-access-control-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-bradner-access-control-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-bradner-access-control-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960805123617.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-bradner-access-control-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-bradner-access-control-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960805123617.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05435; 6 Aug 96 9:32 EDT
Received: from localhost by ietf.org id aa04416; 6 Aug 96 9:19 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipsec at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-skip-mc-01.txt
Date: Tue, 06 Aug 1996 09:18:59 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608060919.aa04416 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : SKIP Extensions for IP Multicast
Author(s) : A. Aziz, T. Markson, H. Prafullchandra
Filename : draft-ietf-ipsec-skip-mc-01.txt
Pages : 20
Date : 08/05/1996
This document describes extensions to the base SKIP [1] protocol to allow
encrypted/authenticated multicast communications.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-skip-mc-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-mc-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-skip-mc-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960805161131.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-skip-mc-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-skip-mc-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960805161131.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05418; 6 Aug 96 9:32 EDT
Received: from localhost by ietf.org id aa04400; 6 Aug 96 9:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipsec at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-skip-adp-01.txt
Date: Tue, 06 Aug 1996 09:18:57 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608060918.aa04400 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : SKIP Algorithm Discovery Protocol
Author(s) : A. Aziz, T. Markson, H. Prafullchandra
Filename : draft-ietf-ipsec-skip-adp-01.txt
Pages : 7
Date : 08/05/1996
SKIP [1] provides privacy and authentication with Internet Protocols.
It does not define a method by which two entities may mutually agree on
encryption, authentication and compression algorithms. We describe a
protocol which will allow one SKIP entity to inform another entity of
the capabilities it supports.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-skip-adp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-adp-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-skip-adp-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960805160054.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-skip-adp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-skip-adp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960805160054.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05438; 6 Aug 96 9:32 EDT
Received: from localhost by ietf.org id aa04367; 6 Aug 96 9:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: cat-ietf at mit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-cat-gssv2-cbind-02.txt
Date: Tue, 06 Aug 1996 09:18:51 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608060918.aa04367 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Common Authentication
Technology Working Group of the IETF.
Title : Generic Security Service API Version 2 : C-bindings
Author(s) : J. Wray
Filename : draft-ietf-cat-gssv2-cbind-02.txt
Pages : 90
Date : 08/05/1996
This draft document specifies C language bindings for Version 2 of the
Generic Security Service Application Program Interface (GSSAPI), which is
described at a language-independent conceptual level in other drafts
[GSSAPI]. It revises RFC-1509, making specific incremental changes in
response to implementation experience and incremental changes in response
to implementation experience and liaison requests. It is intended,
therefore, that this draft or a successor version thereof will become the
basis for subsequent progression of the GSS-API specification on the
standards track.
The Generic Security Service Application Programming Interface
provides security services to its callers, and is intended for
implementation atop a variety of underlying cryptographic mechanisms.
Typically, GSSAPI callers will be application protocols into which security
enhancements are integrated through invocation of services provided by the
GSSAPI. The GSSAPI allows a caller application to authenticate a principal
identity associated with a peer application, to delegate rights to a peer,
and to apply security services such as confidentiality and integrity on a
per-message basis.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-cat-gssv2-cbind-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-gssv2-cbind-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-cat-gssv2-cbind-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960805130008.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-cat-gssv2-cbind-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-gssv2-cbind-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960805130008.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05439; 6 Aug 96 9:32 EDT
Received: from localhost by ietf.org id aa04384; 6 Aug 96 9:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipsec at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-skip-x509-01.txt
Date: Tue, 06 Aug 1996 09:18:55 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608060918.aa04384 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : X.509 Encoding of Diffie-Hellman Public Values
Author(s) : A. Aziz, T. Markson, H. Prafullchandra
Filename : draft-ietf-ipsec-skip-x509-01.txt
Pages : 6
Date : 08/05/1996
This document describes the ASN.1 [1] encoding of the CCITT 1988 X.509 [2]
certificate with Diffie-Hellman public values for use with SKIP [5].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-skip-x509-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-x509-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-skip-x509-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960805155442.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-skip-x509-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-skip-x509-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960805155442.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05576; 6 Aug 96 9:32 EDT
Received: from ietf.org by ietf.org id aa05426; 6 Aug 96 9:32 EDT
Received: from localhost by ietf.org id aa04335; 6 Aug 96 9:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-mutz-http-attributes-01.txt
Date: Tue, 06 Aug 1996 09:18:46 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608060918.aa04335 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : User-Agent Display Attributes
Author(s) : A. Mutz, L. Montulli, L. Masinter
Filename : draft-mutz-http-attributes-01.txt
Pages : 4
Date : 08/05/1996
User-Agent Display Attributes Headers provide a means for an HTTP client
[3] and server to negotiate for content dependent on the client display
capabilities. This memo describes the syntax for introducing this
information into an HTTP transmission. The intent is to present resource
variants when available [5] such that a capable server may present
documents in a preferred form to a client. If such a preferred form is not
available, the server should still provide the requested documents.
This specification is intended as an extension to HTTP/1.1 [4],
to be implemented using a content negotiation method such as
transparent content negotiation [5].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-mutz-http-attributes-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-mutz-http-attributes-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-mutz-http-attributes-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960805124305.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-mutz-http-attributes-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-mutz-http-attributes-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960805124305.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05562; 6 Aug 96 9:32 EDT
Received: from ietf.org by ietf.org id aa05428; 6 Aug 96 9:32 EDT
Received: from localhost by ietf.org id aa04351; 6 Aug 96 9:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ion at nexen.com
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ion-fr-update-01.txt
Date: Tue, 06 Aug 1996 09:18:49 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608060918.aa04351 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internetworking Over NBMA
Working Group of the IETF.
Title : Multiprotocol Interconnect over Frame Relay
Author(s) : C. Brown, A. Malis
Filename : draft-ietf-ion-fr-update-01.txt
Pages : 33
Date : 08/05/1996
This memo describes an encapsulation method for carrying network
interconnect traffic over a Frame Relay backbone. It covers aspects of
both Bridging and Routing.
Systems with the ability to transfer both the encapsulation method
described in this document, and others must have a priori knowledge of
which virtual circuits will carry which encapsulation method and this
encapsulation must only be used over virtual circuits that have been
explicitly configured for its use.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ion-fr-update-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-fr-update-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ion-fr-update-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960805125202.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-fr-update-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-fr-update-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960805125202.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05441; 6 Aug 96 9:32 EDT
Received: from localhost by ietf.org id aa04432; 6 Aug 96 9:19 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipsec at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-skip-pfs-01.txt
Date: Tue, 06 Aug 1996 09:19:01 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608060919.aa04432 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : SKIP extension for Perfect Forward Secrecy (PFS)
Author(s) : A. Aziz
Filename : draft-ietf-ipsec-skip-pfs-01.txt
Pages : 11
Date : 08/05/1996
This document describes an optional extension specifying how to use an
ephemeral Diffie-Hellman exchange in conjunction with the SKIP protocol in
order to provide perfect forward secrecy for situations where forward
secrecy is necessary.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-skip-pfs-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-pfs-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-skip-pfs-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960805161609.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-skip-pfs-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-skip-pfs-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960805161609.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16747; 6 Aug 96 13:38 EDT
Received: from localhost by ietf.org id aa16404; 6 Aug 96 13:24 EDT
To: IETF-Announce: ;
cc: http-wg at cuckoo.hpl.hp.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: Proposed HTTP State Management Mechanism to Proposed
Standard
Reply-to: iesg at ietf.org
Date: Tue, 06 Aug 1996 13:24:00 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9608061324.aa16404 at ietf.org>
The IESG has received a request from the HyperText Transfer Protocol
Working Group to consider "Proposed HTTP State Management Mechanism"
<draft-ietf-http-state-mgmt-03.txt, .ps> for the status of Proposed
Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by August 20, 1996.
Received: from ietf.org by ietf.org id aa16989; 6 Aug 96 13:44 EDT
Received: from localhost by ietf.org id aa16883; 6 Aug 96 13:41 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: IMAP4 extensions to Proposed Standard
Reply-to: iesg at ietf.org
Date: Tue, 06 Aug 1996 13:41:52 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9608061341.aa16883 at ietf.org>
The IESG has received a request to consider the following three
Internet-Drafts as Proposed Standards:
1. IMAP4 QUOTA extension <draft-myers-imap-quota-01.txt>
2. IMAP4 ACL extension <draft-myers-imap-acl-03.txt>
3. IMAP4 non-synchroniziong literals <draft-myers-imap-literal-01.txt>
These has been reviewed in the IETF but are not the product of an
IETF Working Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by September 6, 1996.
Received: from ietf.org by ietf.org id aa22096; 6 Aug 96 17:03 EDT
Received: from cnri by ietf.org id aa22092; 6 Aug 96 17:03 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa14950; 6 Aug 96 17:03 EDT
Received: from ietf.org by ietf.org id aa22083; 6 Aug 96 17:03 EDT
Received: from burnout.cts.com by ietf.org id aa22069; 6 Aug 96 17:03 EDT
Received: from netguru.cts.com (kent-england.pbi.net [206.13.1.58]) by burnout.cts.com (8.6.12/8.6.9) with SMTP id OAA27811; Tue, 6 Aug 1996 14:03:12 -0700
Message-Id: <2.2.32.19960806210825.006da7ec at mail.cts.com>
X-Sender: kwe at mail.cts.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 06 Aug 1996 14:08:25 -0700
To: cidrd at iepg.org, iesg at ietf.org, ietf at ietf.org
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: "Kent W. England" <kwe at 6sigmanets.com>
Subject: Re: IESG review of draft-hubbard-registry-guidelines-03.txt
Cc: piara at apnic.net
Dear Internet Operations and Protocol Standards Folks;
When I first became a network manager my employer gave me a budget for
computer terminals and told me to allocate (or was it assign?) them
appropriately within the manufacturing plant where I worked.
When I became a network manager at my next employer, my boss gave me a
simple mandate "Kent, run it like a business." and the advice "We can't
possibly anticipate the demand for LANs and budget for it ourselves. The
users will have to buy the networks from you. And if they don't like your
price they can hire someone else, but you set the standards for wire and
transport protocol."
Of course you know which situation worked best and which was the more
enjoyable job.
Well, protocol-folks, get your head up out of the sand -- there is work for
you here. Help the operations-folks move this issue from the current state
of affairs where David/Randy, Kim, Mark, et al are in the impossible
situation of rationing addresses and managing the .COM domain and move this
into a market-driven operation.
Operations-folks, we have to make the PIARA experiment work. Else it is
forever and always arguing over what Randy/David and Mark et al are up to.
Let's make the BCP argument moot -- let the market decide. We need open
iTLDs and PIARA.
Thank you, IESG, for your analysis. Reading your comments was like a breath
of fresh air. Thank you, Randy/David for running the AP-NIC. Thank you, Mark
and Kim. It's an impossible job, but very important. You never can satisfy
the demands for a rationed limited resource.
Thank you Steve and Tony for stepping up to the PIARA task. We need everyone
to get behind this idea and make it real. It *needs* to happen in IETF,
protocol-folks. Only then can it move to the marketplace and some other form
of support.
Then David/Randy can do his job as he sees fit, confident in the knowledge
that he is serving his market as he sees it and that whoever doesn't like it
has elsewhere to go.
--Kent
~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~
Kent W. England Six Sigma Networks
1655 Landquist Drive, Suite 100 Voice/Fax: 619.632.8400
Encinitas, CA 92024 kwe at 6SigmaNets.com
Experienced Internet Consulting ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~
Received: from ietf.org by ietf.org id aa24108; 6 Aug 96 20:20 EDT
Received: from cnri by ietf.org id aa24104; 6 Aug 96 20:20 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17824;
6 Aug 96 20:20 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <XAA12705 at pad-thai.cam.ov.com>; Tue, 6 Aug 1996 23:47:35 GMT
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA14180; Tue, 6 Aug 96 19:47:27 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA15406; Tue, 6 Aug 1996 19:47:26 -0400
Date: Tue, 6 Aug 1996 19:47:26 -0400
Message-Id: <9608062347.AA15406 at dcl.MIT.EDU>
Sender:ietf-archive-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: John Linn <linn at cam.ov.com>
Cc: D.Pinkas at frcl.bull.fr, cat-ietf at mit.edu, linn at cam.ov.com
In-Reply-To: John Linn's message of Mon, 29 Jul 1996 13:53:51 -0400,
<199607291753.NAA16795 at winkl.cam.ov.com>
Subject: Re: Regarding sneg-mech
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Cc: cat-ietf at MIT.EDU, linn at cam.ov.com
Date: Mon, 29 Jul 1996 13:53:51 -0400
From: John Linn <linn at cam.ov.com>
>The `snego' exchange should (logically) be, in sequence:
>
> - cleartext negotiation to find common mechanism
> - crypto negotiation to establish mechanism
> - exchange of MAC of negotiation parameters
>
Denis responded, excerpting:
>If we could have a standard way to piggy back the negotiation token and
>the first init token, I would say that this would be valuable.
Questions: is it feasible to treat this case in the draft? Can this
form of protected negotiation be accomplished in a
mechanism-independent fashion by expressing its definition in terms of
where/how the chosen common mechanism's gss_seal() and/or gss_sign()
are applied?
There's a very easy way of dealing with this: Simply specify that during
the gss_{init,accept}_context exchange, after gss_{init,accept}_context
returns GSS_S_COMPLETE, concatenate a token generated by gss_sign
containing the negotiation parameter (if no token is needed, just simply
send the gss_sign token). (I'm neglecting here the framing that we
would need to add so that the it's possible to disambiguate where the
context establishment token ends and the gss_seal token begins.)
This way, if a mechanism only needs to send a single context
establishment token, the MAC of the negotiation parameters is
automatically piggybacked on the token. However, if the mechanism
requires several round trips, this scheme also provides quite nicely for
such schemes, piggybacking the MAC with the last context establishment
token.
- Ted
Received: from ietf.org by ietf.org id aa24548; 6 Aug 96 20:52 EDT
Received: from cnri by ietf.org id aa24544; 6 Aug 96 20:52 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18178;
6 Aug 96 20:52 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <AAA14144 at pad-thai.cam.ov.com>; Wed, 7 Aug 1996 00:25:25 GMT
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA16275; Tue, 6 Aug 96 20:25:23 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA15460; Tue, 6 Aug 1996 20:25:22 -0400
Date: Tue, 6 Aug 1996 20:25:22 -0400
Message-Id: <9608070025.AA15460 at dcl.MIT.EDU>
Sender:ietf-archive-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: John Gardiner Myers <jgm at cmu.edu>
Cc: cat-ietf at mit.edu
In-Reply-To: John Gardiner Myers's message of Fri, 2 Aug 1996 13:30:08 -0400
(EDT), <Am0XgUi00WBw0Yk_00 at andrew.cmu.edu>
Subject: Re: CAT WG Review Last-Call: draft-myers-auth-sasl-04.txt
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Fri, 2 Aug 1996 13:30:08 -0400 (EDT)
From: John Gardiner Myers <jgm at CMU.EDU>
John Linn <linn at cam.ov.com> writes:
> (1) The section proposes that IANA act as a comment clearinghouse,
> [...]. I'm not aware of precedent for IANA assuming
> this role with other registered objects: is there precedent for IANA
> taking on this responsibility, and/or has it been accepted by the IANA
> for this case?
This text was lifted from draft-ietf-822ext-mime-reg-04.txt, which I
believe is currently in IETF-wide Last Call.
It may be perhaps be the text in the MIME registration, but it would
make more sense to require that the IANA maintain a registry of whoever
is the current contact point for a particular mechanism, so that people
could contact the mechanism owner directly, instead of requiring the
IANA to forward comments. This indirect approach seems somewhat silly.
(Unless we think its worthwhile to allow someone to reserve a name in a
public namespace without making public who has reserved such a name, but
it's not clear this is actually desireable.)
Also, instead of making it optional for there to be an informational
RFC, I think it should be made mandatory. This seems fair; if the IANA
is going to register it in a public namespace, there should be a public
definition of what the IANA is actually registering. If someone wants
to do something proprietary, it should be using some sort of
experimental prefix (e.g., X-MACROHARD-UNREGISTERED-PROPRIETARY-STANDARD.)
- Ted
Received: from ietf.org by ietf.org id aa24619; 6 Aug 96 21:02 EDT
Received: from cnri by ietf.org id aa24615; 6 Aug 96 21:02 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18287;
6 Aug 96 21:02 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <AAA14511 at pad-thai.cam.ov.com>; Wed, 7 Aug 1996 00:40:21 GMT
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA17151; Tue, 6 Aug 96 20:40:19 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA15466; Tue, 6 Aug 1996 20:40:18 -0400
Date: Tue, 6 Aug 1996 20:40:18 -0400
Message-Id: <9608070040.AA15466 at dcl.MIT.EDU>
Sender:ietf-archive-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: RL Bob Morgan <Bob.Morgan at stanford.edu>
Cc: cat-ietf at mit.edu
In-Reply-To: RL "Bob" Morgan's message of Fri, 2 Aug 96 12:44:58 -0700,
<Mailstrom.1.06.43210.3853.morgan at networking.stanford.edu>
Subject: Re: Ident and SASL
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
It's not clear that the CAT list is the best place to discuss S/Indent,
but since there hasn't been any discussion to the contrary, I'll just
make one comment here.
The text of draft-morgan-ident-ext-00.txt states:
In response to the first request message, the responder sends a
message whose auth-resp-info field is a Kerberos ticket and an
authenticator for the service principal "ident.hostname at realm", where
"ident" is the service name, "hostname" is the first component of the
host name of the server with all letters in lower case, and where
"realm" is the Kerberos realm of the server. The client principal is
the principal associated with the owner of the connection specified
in the request. As specified in SASL, the encrypted checksum field
included within the Kerberos authenticator contains the server
provided challenge in network byte order.
This means that on a Unix time sharing machine, when querying machine
asks the ident server for an authenticated "who is using this
connection", the ident server (which is typically running as the
superuser) has to search its system to try to find the Kerberos credentials
of the user whose connection is being requested, and then "steal" (ok,
borrow) the credentials in order to make an authenticated connection as
this user back to the requesting party.
This is a little bit backwards --- as are many things in the whole IDENT
protocol, which is why the IDENT protocol often leaves a bad taste in
many people's mouths.
There's also an interesting man-in-the-middle attack that can be
performed, by changing the (unauthenticated) ports requested by the
requester before they reach the ident server. It is true that the port
numbers are sent in an authenticated fashion from the S/ident server
back to the requestor. If however, a (badly implemented) requestor
doesn't check these port numbers, but just takes the Kerberos
authentication (which must be good, we're using Kerberos, right?)
without doing any further checking, they can be open themselves to a
nasty substitution attack.
- Ted
Received: from ietf.org by ietf.org id aa01165; 6 Aug 96 23:22 EDT
Received: from cnri by ietf.org id aa01161; 6 Aug 96 23:22 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa00439;
6 Aug 96 23:22 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <CAA20121 at pad-thai.cam.ov.com>; Wed, 7 Aug 1996 02:57:58 GMT
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AB25073; Tue, 6 Aug 96 22:57:55 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA15605; Tue, 6 Aug 1996 22:57:54 -0400
Date: Tue, 6 Aug 1996 22:57:54 -0400
Message-Id: <9608070257.AA15605 at dcl.MIT.EDU>
Sender:ietf-archive-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: cat-ietf at mit.edu
Subject: Re: gss_import_name...
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Wed, 31 Jul 96 08:02:51 EDT
From: "John Wray, Digital DPE, (508) 486-5210 31-Jul-1996 0746" <wray at tuxedo.ENET.dec.com>
I don't see the use of GSS_C_NULL_OID as a conflict between the base
spec and the C bindings, but if this appears to be a problem, an
alternative would be to define an OID within gssapi.h that means
"local default".
What I'd really like to see is some tightening up of the language of
what GSS_C_NULL_OID beyond "local system-specific printable syntax".
I think it should be clear that this is the local system-specific syntax
for naming _users_, since we already have GSS_C_NT_HOSTBASED_SERVICE for
naming services, per the latest gssv2 draft.
- Ted
Received: from ietf.org by ietf.org id aa10443; 7 Aug 96 9:48 EDT
Received: from localhost by ietf.org id aa09871; 7 Aug 96 9:34 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: fddi-mib at cs.utk.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-fddimib-objects-v2-01.txt
Date: Wed, 07 Aug 1996 09:34:22 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608070934.aa09871 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the FDDI MIB Working Group of
the IETF.
Title : FDDI Management Information Base
Author(s) : J. Case, A. Rijsinghani
Filename : draft-ietf-fddimib-objects-v2-01.txt
Pages : 63
Date : 08/06/1996
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it defines objects for managing devices which implement the
FDDI based on the ANSI FDDI SMT Standard X3.229-1994 [8]. Note that the
technical content of this standard is identical to that of the ANSI SMT
version 7.3 draft standard.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-fddimib-objects-v2-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-fddimib-objects-v2-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-fddimib-objects-v2-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960806150944.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-fddimib-objects-v2-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-fddimib-objects-v2-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960806150944.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa10442; 7 Aug 96 9:48 EDT
Received: from localhost by ietf.org id aa09887; 7 Aug 96 9:34 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: fddi-mib at cs.utk.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-fddimib-smiv2-object-v2-00.txt
Date: Wed, 07 Aug 1996 09:34:26 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608070934.aa09887 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the FDDI MIB Working Group of
the IETF.
Title : FDDI Management Information Base in the SNMPv2 SMI
Author(s) : J. Case, A. Rijsinghani
Filename : draft-ietf-fddimib-smiv2-object-v2-00.txt
Pages : 66
Date : 08/06/1996
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it defines objects for managing devices which implement the
FDDI based on the ANSI FDDI SMT Standard X3.229-1994 [8]. Note that the
technical content of this standard is identical to that of the ANSI SMT
version 7.3 draft standard.
The MIB module contained in this memo is updated to be defined using
the SNMPv2 SMI [9], but is otherwise identical to that contained in [11].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-fddimib-smiv2-object-v2-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-fddimib-smiv2-object-v2-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-fddimib-smiv2-object-v2-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960806151610.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-fddimib-smiv2-object-v2-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-fddimib-smiv2-object-v2-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960806151610.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa10440; 7 Aug 96 9:48 EDT
Received: from localhost by ietf.org id aa09903; 7 Aug 96 9:34 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ruth-cdpd-networks-00.txt
Date: Wed, 07 Aug 1996 09:34:30 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608070934.aa09903 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Interworking Between CDPD and Mobile IP Networks
Author(s) : G. Ruth, R. Yuan
Filename : draft-ruth-cdpd-networks-00.txt
Pages : 12
Date : 08/06/1996
Two protocols, CDPD (Cellular Digital Packet Data) and Mobile-IP have been
developed by the CDPD Forum and IETF (Internet Engineering Task Force)
respectively to address the issue of providing seamless network access to
mobile data devices. In this memo a scheme is proposed for the two networks
to interwork together and to support seamless migration of mobile data
devices between the networks.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ruth-cdpd-networks-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ruth-cdpd-networks-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ruth-cdpd-networks-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960806160048.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ruth-cdpd-networks-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ruth-cdpd-networks-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960806160048.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17992; 7 Aug 96 13:59 EDT
Received: from cnri by ietf.org id aa17987; 7 Aug 96 13:59 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12056;
7 Aug 96 13:59 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <RAA20370 at pad-thai.cam.ov.com>; Wed, 7 Aug 1996 17:17:58 GMT
Received: from mail13.digital.com by MIT.EDU with SMTP
id AA12005; Wed, 7 Aug 96 13:17:56 EDT
Received: from us1rmc.bb.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV)
id NAA13823; Wed, 7 Aug 1996 13:03:18 -0400 (EDT)
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA27252; Wed, 7 Aug 96 13:04:18 -0400
Message-Id: <9608071704.AA27252 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Wed, 7 Aug 96 13:04:18 EDT
Date: Wed, 7 Aug 96 13:04:18 EDT
Sender:ietf-archive-request at ietf.org
From: "John Wray, Digital DPE, (508) 486-5210 07-Aug-1996 1229" <wray at tuxedo.enet.dec.com>
To: "cat-ietf at mit.edu"@in.enet.dec.com
Cc: wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu
Subject: GSSV2 C-bindings
In my haste to get the C-bindings out as close as possible to my July target, I
seem to have missed out a couple things. The routine
gss_inquire_mechs_for_name() was omitted in the latest draft, as were the
name-type OIDs from section 4 of the high-level spec.
I have corrected these omissions in my copy of the draft (the changes are
appended to this message), and will shortly submit an updated version of the
ID; however, I think it's worth holding on for a couple weeks to see if anyone
spots any other obvious errors or omissions in the current document.
John
================================================================================
New section 7.23, as below. Subsequent sections renumbered to suit.
================================================================================
7.23. gss_inquire_mechs_for_name
OM_uint32 gss_inquire_names_for_mech (
OM_uint32 * minor_status,
gss_name_t input_name,
gss_OID_set * mech_types)
Purpose:
Returns the set of mechanisms supported by the GSSAPI implementation
that may be able to process the specified name.
Each mechanism returned will recognize at least one element within
the name. It is permissible for this routine to be implemented
within a mechanism-independent GSSAPI layer, using the type
information contained within the presented name, and based on
registration information provided by individual mechanism
implementations. This means that the returned mech_types set may
indicate that a particular mechanism will understand the name when in
fact it would refuse to accept the name as input to
gss_canonicalize_name, gss_init_sec_context, gss_acquire_cred or
gss_add_cred (due to some property of the specific name, as opposed
to the name type). Thus this routine should be used only as a pre-
filter for a call to a subsequent mechanism-specific routine.
Parameters:
minor_status Integer, modify
Implementation specific status code.
input_name gss_name_t, read
The name to which the inquiry relates.
mech_types gss_OID_set, modify
Set of mechanisms that may support the
specified name. The returned OID set
must be freed by the caller by a call
to gss_release_oid_set.
Function value:
GSS status code:
GSS_S_COMPLETE Successful completion
GSS_S_BAD_NAME The input_name parameter was ill-formed.
GSS_S_BAD_NAMETYPE The input_name parameter contained an invalid or
unsupported type of name
================================================================================
Add following two fragments to gssapi.h in appropriate places
================================================================================
OM_uint32 gss_inquire_mechs_for_name (
OM_uint32 *, /* minor_status */
gss_name_t, /* input_name */
gss_OID_set * /* mech_types */
);
================================================================================
/*
* The implementation must reserve static storage for a
* gss_OID_desc object containing the value
* {10, (void *)"\\x2a\\x86\\x48\\x86\\xf7\\x12"
* "\\x01\\x02\\x01\\x01"},
* corresponding to an object-identifier value of
* {iso(1) member-body(2) United States(840) mit(113554)
* infosys(1) gssapi(2) generic(1) user_name(1)}. The constant
* GSS_C_NT_USER_NAME should be initialized to point
* to that gss_OID_desc.
*/
extern gss_OID GSS_C_NT_USER_NAME;
/*
* The implementation must reserve static storage for a
* gss_OID_desc object containing the value
* {10, (void *)"\\x2a\\x86\\x48\\x86\\xf7\\x12"
* "\\x01\\x02\\x01\\x02"},
* corresponding to an object-identifier value of
* {iso(1) member-body(2) United States(840) mit(113554)
* infosys(1) gssapi(2) generic(1) machine_uid_name(2)}.
* The constant GSS_C_NT_MACHINE_UID_NAME should be
* initialized to point to that gss_OID_desc.
*/
extern gss_OID GSS_C_NT_MACHINE_UID_NAME;
/*
* The implementation must reserve static storage for a
* gss_OID_desc object containing the value
* {10, (void *)"\\x2a\\x86\\x48\\x86\\xf7\\x12"
* "\\x01\\x02\\x01\\x03"},
* corresponding to an object-identifier value of
* {iso(1) member-body(2) United States(840) mit(113554)
* infosys(1) gssapi(2) generic(1) string_uid_name(3)}.
* The constant GSS_C_NT_STRING_UID_NAME should be
* initialized to point to that gss_OID_desc.
*/
extern gss_OID GSS_C_NT_STRING_UID_NAME;
/*
* The implementation must reserve static storage for a
* gss_OID_desc object containing the value
* {6, (void *)"\\x2b\\x06\\x01\\x05\\x06\\x02"},
* corresponding to an object-identifier value of
* {1(iso), 3(org), 6(dod), 1(internet), 5(security),
* 6(nametypes), 2(gss-host-based-services)}. The constant
* GSS_C_NT_HOSTBASED_SERVICE should be initialized to point
* to that gss_OID_desc.
*/
extern gss_OID GSS_C_NT_HOSTBASED_SERVICE;
Received: from ietf.org by ietf.org id aa19283; 7 Aug 96 14:55 EDT
Received: from localhost by ietf.org id aa18782; 7 Aug 96 14:35 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Document Action: Local Mail Transfer Protocol to Informational
Date: Wed, 07 Aug 1996 14:35:51 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9608071435.aa18782 at ietf.org>
The IESG has reviewed the Internet-Draft "Local Mail Transfer
Protocol" <draft-myers-lmtp-00.txt> and recommends that it be
published by the RFC Editor as an Informational RFC. The IESG contact
person is Keith Moore.
Received: from ietf.org by ietf.org id aa19789; 7 Aug 96 15:01 EDT
Received: from localhost by ietf.org id aa19436; 7 Aug 96 14:58 EDT
To: IETF-Announce: ;
cc: ipsec at tis.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: HMAC-IP Authentication with Replay Prevention to
Proposed Standard
Reply-to: iesg at ietf.org
Date: Wed, 07 Aug 1996 14:58:16 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9608071458.aa19436 at ietf.org>
The IESG has received a request from the IP Security Protocol Working
Group to consider the following Internet-Drafts for Proposed Standard:
1. HMAC-MD5 IP Authentication with Replay Prevention
<draft-ietf-ipsec-ah-hmac-md5-01.txt>
2. HMAC-SHA IP Authentication with Replay Prevention
<draft-ietf-ipsec-ah-hmac-sha-01.txt>
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by August 20, 1996.
Received: from ietf.org by ietf.org id aa26030; 7 Aug 96 21:37 EDT
Received: from cnri by ietf.org id aa26026; 7 Aug 96 21:37 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa18870; 7 Aug 96 21:37 EDT
Received: from ietf.org by ietf.org id aa26017; 7 Aug 96 21:37 EDT
Received: from fire1.sprintlink.net by ietf.org id aa26004; 7 Aug 96 21:37 EDT
Received: from mercury.int.sprintlink.net ([206.229.244.25]) by fire1.sprintlink.net
via smtpd (for ietf.org [132.151.1.19]) with SMTP; 8 Aug 1996 01:38:27 UT
Received: (from mhidalgo at localhost) by mercury.int.sprintlink.net (8.7.3/8.6.12) id VAA29529; Wed, 7 Aug 1996 21:36:36 -0400 (EDT)
Date: Wed, 7 Aug 1996 21:36:36 -0400 (EDT)
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: "Marc E. Hidalgo" <mhidalgo at sprint.net>
X-Sender: mhidalgo at mercury.int.sprintlink.net
To: Robert Elz <hostmaster at munnari.oz.au>
cc: mathias at staff.singnet.com.sg, cidrd at iepg.org, iesg at ietf.org,
ietf at ietf.org
Subject: Re: IESG review of draft-hubbard-registry-guidelines-03.txt
In-Reply-To: <7339.838987031 at munnari.OZ.AU>
Message-ID: <Pine.SV4.3.91.960807213419.19390B-100000 at mercury.int.sprintlink.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 2 Aug 1996, Robert Elz wrote:
>
> Read the docs.
>
jeez - i used to ban staff to cobol programming for using such a cop-out.
Marc
Received: from ietf.org by ietf.org id aa12539; 8 Aug 96 9:34 EDT
Received: from localhost by ietf.org id aa11979; 8 Aug 96 9:26 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-borman-jumbograms-00.txt
Date: Thu, 08 Aug 1996 09:26:08 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608080926.aa11979 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : TCP and UDP over IPv6 Jumbograms
Author(s) : D. Borman
Filename : draft-borman-jumbograms-00.txt
Pages : 2
Date : 08/07/1996
IPv6 supports datagrams larger than 65535 bytes long, called jumbograms.
The UDP protocol has a 16 length field that keeps it from being able to
make use of jumbograms, and though TCP does not have a length field, it
does have an MSS option that has a 65535 byte length limitation. This
document describes some simple changes that can be made to TCP and UDP over
IPv6 to allow them to take advantage of jumbograms.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-borman-jumbograms-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-borman-jumbograms-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-borman-jumbograms-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960807150135.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-borman-jumbograms-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-borman-jumbograms-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960807150135.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12541; 8 Aug 96 9:34 EDT
Received: from localhost by ietf.org id aa12009; 8 Aug 96 9:26 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-teow-fabric-mib-01.txt
Date: Thu, 08 Aug 1996 09:26:11 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608080926.aa12009 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Definitions of Managed Objects for the Fabric Element
in Fibre Channel Standard
Author(s) : K. Teow
Filename : draft-teow-fabric-mib-01.txt
Pages : 49
Date : 08/07/1996
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it defines the objects for managing the
operations of the Fabric Element portion of the Fibre Channel Standard
defined in [1], [2] and [3].
This memo specifies a MIB module in a manner that is both compliant to
the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
There is a companion memo [10], that defines the objects for managing the
operations of the Node portion of the Fibre Channel Standard (FC).
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-teow-fabric-mib-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-teow-fabric-mib-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-teow-fabric-mib-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960807164025.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-teow-fabric-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-teow-fabric-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960807164025.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12534; 8 Aug 96 9:34 EDT
Received: from localhost by ietf.org id aa11987; 8 Aug 96 9:26 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-hurn-01.txt
Date: Thu, 08 Aug 1996 09:26:10 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608080926.aa11987 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Extending NAT
Author(s) : M. Hurn
Filename : draft-rfced-info-hurn-01.txt
Pages : 4
Date : 08/07/1996
This document describes how the addressing scheme of the 'IP Network
Address Translator (NAT) [1] could be extended. The extension takes
advantage of the fact that the source port number in a full TCP/IP packet
can be any value the originating host is not currently using. It also
exploits the fact that (nearly) all the networking software will work with
DNS. By using DNS and proxies the ENAT systems perform the address
translation indirectly.
For convenience the term ENAT will be used for the extended addressing
scheme to distinguish it from the original. A ENAT system could be used
equally for UDP/IP as well as TCP/IP. ICMP can be handled with
restrictions.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-rfced-info-hurn-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-hurn-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-hurn-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960807163301.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-hurn-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-hurn-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960807163301.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12614; 8 Aug 96 9:34 EDT
Received: from ietf.org by ietf.org id aa12542; 8 Aug 96 9:34 EDT
Received: from localhost by ietf.org id aa11960; 8 Aug 96 9:26 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-hubbard-registry-guidelines-04.txt
Date: Thu, 08 Aug 1996 09:26:06 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608080926.aa11960 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Note: This revision reflects comments received during the last call period.
Title : INTERNET REGISTRY IP ALLOCATION GUIDELINES
Author(s) : K. Hubbard, M. Kosters, D. Conrad,
D. Karrenberg, J. Postel
Filename : draft-hubbard-registry-guidelines-04.txt
Pages : 13
Date : 08/07/1996
This document describes the registry system for the distribution of
globally unique Internet address space and registry operations.
Particularly this document describes the rules and guidelines governing
the distribution of this address space.
This document replaces RFC 1466, with all the guidelines and
procedures updated and modified in the light of experience.
This document does not describe private Internet address space
and multicast address space. It also does not describe regional
and local refinements of the global rules and guidelines.
This document can be considered the base set of operational guidelines
in use by all registries. Additional guidelines may be imposed
by a particular registry as appropriate.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-hubbard-registry-guidelines-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hubbard-registry-guidelines-04.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-hubbard-registry-guidelines-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960807134601.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hubbard-registry-guidelines-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hubbard-registry-guidelines-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960807134601.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12636; 8 Aug 96 9:34 EDT
Received: from ietf.org by ietf.org id aa12545; 8 Aug 96 9:34 EDT
Received: from localhost by ietf.org id aa11944; 8 Aug 96 9:26 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ids at umich.edu
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ids-dnsnames-01.txt
Date: Thu, 08 Aug 1996 09:26:03 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608080926.aa11944 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integrated Directory
Services Working Group of the IETF.
Title : Use of DNS Aliases for Network Services
Author(s) : M. Hamilton, R. Wright
Filename : draft-ietf-ids-dnsnames-01.txt
Pages : 10
Date : 08/07/1996
It has become a common practice to use symbolic names (usually CNAMEs)
in the Domain Name Service (DNS - [1,2]) to refer to network services
such as anonymous FTP [3] servers, Gopher [4] servers, and most
notably World-Wide Web HTTP [5] servers. This is desirable for
a number of reasons. It provides a way of moving services from
one machine to another transparently, and a mechanism by which people
or agents may programatically discover that an organization runs,
say, a World-Wide Web server.
Although this approach has been almost universally adopted, there is no
standards document or similar specification for these commonly used names.
This document seeks to rectify this situation by gathering together the
extant "folklore" on naming conventions, and proposes a mechanism for
accommodating new protocols.
It is important to note that these naming conventions do not provide
a complete long term solution to the problem of finding
a particular network service for a site. There are efforts in
other IETF working groups to address the long term solution to this
problem, such as the Server Location Resource Records (DNS SRV) work.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ids-dnsnames-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ids-dnsnames-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ids-dnsnames-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960807132323.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ids-dnsnames-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ids-dnsnames-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960807132323.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13975; 8 Aug 96 10:15 EDT
Received: from cnri by ietf.org id aa13971; 8 Aug 96 10:15 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa07556;
8 Aug 96 10:15 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <NAA04492 at pad-thai.cam.ov.com>; Thu, 8 Aug 1996 13:44:19 GMT
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA27680; Thu, 8 Aug 96 09:44:11 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <NAA04488 at pad-thai.cam.ov.com>; Thu, 8 Aug 1996 13:44:08 GMT
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id JAA19450; Thu, 8 Aug 1996 09:44:06 -0400
Message-Id: <199608081344.JAA19450 at winkl.cam.ov.com>
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Cc: RL Bob Morgan <Bob.Morgan at stanford.edu>, cat-ietf at mit.edu,
linn at cam.ov.com
Subject: Re: Ident and SASL
In-Reply-To: Your message of "Tue, 06 Aug 1996 20:40:18 EDT."
<9608070040.AA15466 at dcl.MIT.EDU>
Date: Thu, 08 Aug 1996 09:44:05 -0400
Sender:ietf-archive-request at ietf.org
From: John Linn <linn at cam.ov.com>
Given that Ident is a callback facility to ask a host what it can
tell about a particular connection, would it make sense (at least
as an option) for the Ident server to authenticate as a host-level
principal (representing the host, not impersonating the associated
user), and then to deliver the host's assertion of the associated
user's name on the channel protected as a result of that host-level
authentication exchange? As a user, I'd be more comfortable with
a model which applies my credentials only as a result of actions
which I request than with a model where contexts can be initiated
in my name invisibly to me, in response to arbitrary queries which
could be probes unrelated to anything I'm doing.
--jl
Received: from ietf.org by ietf.org id aa15870; 8 Aug 96 11:35 EDT
Received: from cnri by ietf.org id aa15866; 8 Aug 96 11:35 EDT
Received: from neptune.hq.tis.com by CNRI.Reston.VA.US id aa09034;
8 Aug 96 11:35 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa23401; 8 Aug 96 11:05 EDT
Received: from relay.hq.tis.com by neptune.TIS.COM id aa23381;
8 Aug 96 10:59 EDT
Received: by relay.hq.tis.com; id LAA11979; Thu, 8 Aug 1996 11:02:12 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma011952; Thu, 8 Aug 96 11:01:47 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA04033; Thu, 8 Aug 96 11:01:14 EDT
Received: by relay.hq.tis.com; id LAA11939; Thu, 8 Aug 1996 11:01:41 -0400
Received: from janus.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1)
id xma011899; Thu, 8 Aug 96 11:01:10 -0400
Received: by janus.border.com id <18491-2>; Thu, 8 Aug 1996 10:56:38 -0400
Date: Thu, 8 Aug 1996 10:55:11 -0400
Sender:ietf-archive-request at ietf.org
From: Norman Shulman <norm at border.com>
To: iesg at ietf.net
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Cc: ietf at ietf.net, ipsec at tis.com, mjo at tycho.ncsc.mil, rob.glenn at nist.gov
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Subject: <draft-ietf-ipsec-ah-hmac-md5-01.txt>
Message-Id: <96Aug8.105638edt.18491-2 at janus.border.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orig-Sender: ipsec-approval at neptune.tis.com
Precedence: bulk
Comments on <draft-ietf-ipsec-ah-hmac-md5-01.txt>
Page 4, 2.1, paragraph 1: "Protection" should be "Prevention" in two places.
Page 5, 2.2, paragraph 1, line 4:
"zeros" should be "zeros prior to the computation".
Page 5, 2.2, paragraph 2, line 4: "SHA" should be "MD5".
Norman Shulman Border Network Technologies Inc.
Software Engineer Tel 1 416 368 7157 ext 304
norm at border.com Fax 1 416 368 7178
Received: from ietf.org by ietf.org id aa15885; 8 Aug 96 11:35 EDT
Received: from cnri by ietf.org id aa15881; 8 Aug 96 11:35 EDT
Received: from neptune.hq.tis.com by CNRI.Reston.VA.US id aa09040;
8 Aug 96 11:35 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa23628; 8 Aug 96 11:10 EDT
Received: from relay.hq.tis.com by neptune.TIS.COM id aa23611;
8 Aug 96 11:03 EDT
Received: by relay.hq.tis.com; id LAA12267; Thu, 8 Aug 1996 11:06:39 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma012241; Thu, 8 Aug 96 11:06:17 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA04276; Thu, 8 Aug 96 11:05:42 EDT
Received: by relay.hq.tis.com; id LAA12229; Thu, 8 Aug 1996 11:06:09 -0400
Received: from janus.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1)
id xma012224; Thu, 8 Aug 96 11:05:49 -0400
Received: by janus.border.com id <18468-1>; Thu, 8 Aug 1996 11:01:22 -0400
Date: Thu, 8 Aug 1996 10:58:36 -0400
Sender:ietf-archive-request at ietf.org
From: Norman Shulman <norm at border.com>
To: iesg at ietf.net
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Cc: ietf at ietf.net, ipsec at tis.com, shu-jen.chang at nist.gov, rob.glenn at nist.gov
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Subject: <draft-ietf-ipsec-ah-hmac-sha-01.txt>
Message-Id: <96Aug8.110122edt.18468-1 at janus.border.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orig-Sender: ipsec-approval at neptune.tis.com
Precedence: bulk
Comments on <draft-ietf-ipsec-ah-hmac-sha-01.txt>
Page 4, paragraph 2, line 6: Delete the double quote.
Page 4, 1.2, third sentence: Seems to me that the ability to handle unpadded
message digests should either be dropped or made mandatory. If it is optional,
then it adds an element to the security parameter negotiations. If it is
retained, then 2.2(8) must be modified accordingly.
Page 5, paragraph 1: "Protection" should be "Prevention" in two places.
Page 6, 2.2(8): This has to be modified to accommodate an unpadded hash.
Norman Shulman Border Network Technologies Inc.
Software Engineer Tel 1 416 368 7157 ext 304
norm at border.com Fax 1 416 368 7178
Received: from ietf.org by ietf.org id aa19343; 8 Aug 96 14:54 EDT
Received: from cnri by ietf.org id aa19339; 8 Aug 96 14:54 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12407;
8 Aug 96 14:54 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <SAA18044 at pad-thai.cam.ov.com>; Thu, 8 Aug 1996 18:16:26 GMT
Received: from tide21.microsoft.com by MIT.EDU with SMTP
id AA18588; Thu, 8 Aug 96 14:16:23 EDT
Received: by tide21.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5)
id <01BB851B.128DBA70 at tide21.microsoft.com>; Thu, 8 Aug 1996 11:16:40 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-84-MSG-960808181553Z-12285 at tide21.microsoft.com>
Sender:ietf-archive-request at ietf.org
From: Glen Zorn <glennz at microsoft.com>
To: "'Theodore Y. Ts'o'" <tytso at mit.edu>, 'John Linn' <linn at cam.ov.com>
Cc: 'RL Bob Morgan' <Bob.Morgan at stanford.edu>,
"'cat-ietf at mit.edu'" <cat-ietf at mit.edu>
Subject: RE: Ident and SASL
Date: Thu, 8 Aug 1996 11:15:53 -0700
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
Encoding: 23 TEXT
I like that idea a lot.
>----------
>From:John Linn[SMTP:linn at cam.ov.com]
>Sent:Thursday, August 08, 1996 6:44 AM
>To: Theodore Y. Ts'o
>Cc: RL " Bob " Morgan; cat-ietf at mit.edu; linn at cam.ov.com
>Subject:Re: Ident and SASL
>
>Given that Ident is a callback facility to ask a host what it can
>tell about a particular connection, would it make sense (at least
>as an option) for the Ident server to authenticate as a host-level
>principal (representing the host, not impersonating the associated
>user), and then to deliver the host's assertion of the associated
>user's name on the channel protected as a result of that host-level
>authentication exchange? As a user, I'd be more comfortable with
>a model which applies my credentials only as a result of actions
>which I request than with a model where contexts can be initiated
>in my name invisibly to me, in response to arbitrary queries which
>could be probes unrelated to anything I'm doing.
>
>--jl
>
Received: from ietf.org by ietf.org id aa22023; 8 Aug 96 17:16 EDT
Received: from cnri by ietf.org id aa21924; 8 Aug 96 17:07 EDT
Received: from denmark-c.it.earthlink.net by CNRI.Reston.VA.US id aa14665;
8 Aug 96 17:06 EDT
Received: from 206.149.208.133 (max6-gg-ca-33.earthlink.net [206.149.208.133]) by denmark.it.earthlink.net (8.7.5/8.7.3) with SMTP id OAA04816 for <ietf at cnri.reston.va.us>; Thu, 8 Aug 1996 14:06:15 -0700 (PDT)
Message-ID: <320A5865.7573 at earthlink.net>
Date: Thu, 08 Aug 1996 14:13:09 -0700
Sender:ietf-request at ietf.org
From: Damon Danielson <ddanielson at earthlink.net>
X-Mailer: Mozilla 2.01 (Macintosh; I; 68K)
MIME-Version: 1.0
To: ietf at CNRI.Reston.VA.US
Subject: Registration
X-URL: http://www.data.com/cgi-bin/ShowIWatch/Internet
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Please register me for your service.
Gracias.
DD
Received: from ietf.org by ietf.org id aa23835; 8 Aug 96 19:31 EDT
Received: from cnri by ietf.org id aa23831; 8 Aug 96 19:31 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16572;
8 Aug 96 19:31 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <WAA27537 at pad-thai.cam.ov.com>; Thu, 8 Aug 1996 22:42:17 GMT
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA26421; Thu, 8 Aug 96 18:42:13 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA09249; Thu, 8 Aug 1996 18:42:08 -0400
Date: Thu, 8 Aug 1996 18:42:08 -0400
Message-Id: <9608082242.AA09249 at dcl.MIT.EDU>
Sender:ietf-archive-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: John Linn <linn at cam.ov.com>
Cc: "Theodore Y. Ts'o" <tytso at mit.edu>,
RL Bob Morgan <Bob.Morgan at stanford.edu>, cat-ietf at mit.edu,
linn at cam.ov.com
In-Reply-To: John Linn's message of Thu, 08 Aug 1996 09:44:05 -0400,
<199608081344.JAA19450 at winkl.cam.ov.com>
Subject: Re: Ident and SASL
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Thu, 08 Aug 1996 09:44:05 -0400
From: John Linn <linn at cam.ov.com>
Given that Ident is a callback facility to ask a host what it can
tell about a particular connection, would it make sense (at least
as an option) for the Ident server to authenticate as a host-level
principal (representing the host, not impersonating the associated
user), and then to deliver the host's assertion of the associated
user's name on the channel protected as a result of that host-level
authentication exchange? As a user, I'd be more comfortable with
a model which applies my credentials only as a result of actions
which I request than with a model where contexts can be initiated
in my name invisibly to me, in response to arbitrary queries which
could be probes unrelated to anything I'm doing.
Yes, that would be my suggestion as well.
- Ted
Received: from ietf.org by ietf.org id aa24253; 8 Aug 96 20:07 EDT
Received: from nw.com by ietf.org id aa24155; 8 Aug 96 20:04 EDT
Received: (mkl at localhost) by nw.com (8.6.12/8.6.5) id RAA18624 for ietf at ietf.org; Thu, 8 Aug 1996 17:01:12 -0700
Date: Thu, 8 Aug 96 17:01:11 PDT
Sender:ietf-request at ietf.org
From: Mark Lottor <mkl at nw.com>
To: ietf at ietf.org
Subject: Internet Domain Survey, July 1996
Message-ID: <CMM.0.90.4.839548871.mkl at nw.com>
Source-Info: From (or Sender) name not authenticated.
Internet Domain Survey Network Wizards July 1996
The Domain Survey attempts to discover every host on the Internet by doing
a complete search of the Domain Name System. The latest results were
gathered during late July 1996 and a summary is listed below.
For the full report see WWW.NW.COM.
-- Mark Lottor
Number of Hosts, Domains, and Nets Advertised in the Domain Name System
Replied Network Class
Date | Hosts Domains ToPing* A B C
------+-----------------------------------------------------
Jul 96| 12,881,000 488,000 2,569,000 95 5892 128378
Jan 96| 9,472,000 240,000 1,682,000 92 5655 87924
Jul 95| 6,642,000 120,000 1,149,000 91 5390 56057
Jan 95| 4,852,000 71,000 970,000 91 4979 34340
Jul 94| 3,212,000 46,000 707,000 89 4493 20628
Jan 94| 2,217,000 30,000 576,000 74 4043 16422
[* estimated by pinging 1% of all hosts]
Host Distribution by Top-Level Domain Name
[see ftp.nw.com, zone/iso-country-codes to decode names]
3323647 com 25109 hu 1335 lt 99 mc 18 az
2114851 edu 24133 hk 1099 bm 94 mk 14 ky
1232902 net 21464 ie 919 cy 92 zm 11 vi
579492 uk 20253 mx 878 uy 89 aw 10 md
548168 de 17573 pt 817 eg 86 hn 9 mn
496427 jp 13601 su 609 ec 86 fo 9 bb
432727 us 13239 cl 545 kz 85 py 8 sb
431939 mil 12689 gr 476 mt 84 na 8 bz
424356 ca 11282 cn 469 ae 81 ad 7 vu
397460 au 10810 is 386 pk 79 jo 7 bj
361065 gov 9949 si 359 lb 77 al 7 aq
327148 org 9415 ar 351 ma 74 uz 6 qa
277207 fi 8541 my 307 ir 71 pr 6 gh
214704 nl 7743 tr 285 ni 66 tt 6 dj
189786 fr 6605 ee 277 sm 64 gu 6 cf
186312 se 6362 th 275 sa 60 ug 5 vn
120780 no 5498 sk 236 bh 60 np 4 cu
113776 it 5265 co 234 lk 60 gi 4 ci
102691 ch 5262 id 207 pa 58 fj 3 va
83349 za 4499 ua 195 jm 49 sz 3 to
77886 nz 3117 ph 170 bn 47 mu 3 gy
76955 dk 2932 lv 163 ag 46 sn 2 sr
71090 at 2877 lu 159 gt 45 zw 2 ne
62447 es 2725 ro 158 bs 44 ai 2 gn
47973 kr 2582 cr 154 bo 43 sv 2 an
46854 br 2480 hr 140 gl 40 tn 1 ml
43311 be 2269 pe 140 do 40 gb 1 ck
39611 il 2254 bg 134 li 27 dm 1 bf
38432 pl 2176 in 133 ke 26 mz 1 ao
38376 sg 1963 kw 129 mo 23 mg
32219 cz 1930 int 119 ge 20 lc
32022 ru 1679 ve 105 am 19 nc
30645 tw 1631 yu 103 by 18 dz
Received: from ietf.org by ietf.org id aa12086; 9 Aug 96 10:08 EDT
Received: from localhost by ietf.org id aa11539; 9 Aug 96 9:46 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: atommib at thumper.bellcore.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-atommib-sonetng-01.txt
Date: Fri, 09 Aug 1996 09:46:11 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608090946.aa11539 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the AToM MIB Working Group of
the IETF.
Title : Definitions of Managed Objects
for the SONET/SDH Interface Type
Author(s) : K. Tesink
Filename : draft-ietf-atommib-sonetng-01.txt
Pages : 87
Date : 08/08/1996
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing Synchronous
Optical Network/Synchronous Digital Hierarchy (SONET/SDH) objects. This
document is a companion document with Definitions of Managed Objects for
the DS1/E1 and DS3/E3 Interface Types, RFC1406 [14] and RFC1407 [13].
This memo specifies a MIB module in a manner that is both compliant to the
SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-atommib-sonetng-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-sonetng-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-atommib-sonetng-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960808151503.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-atommib-sonetng-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-atommib-sonetng-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960808151503.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12247; 9 Aug 96 10:08 EDT
Received: from ietf.org by ietf.org id aa12080; 9 Aug 96 10:08 EDT
Received: from localhost by ietf.org id aa11523; 9 Aug 96 9:46 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-warwick-tokenring-arch-00.txt
Date: Fri, 09 Aug 1996 09:46:09 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608090946.aa11523 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Dedicated Token Ring Concentrator MIB
Author(s) : K. Lee, T. Warwick
Filename : draft-warwick-tokenring-arch-00.txt
Pages : 38
Date : 08/08/1996
This document contains an extract from Draft 5 of the IEEE standard 802.5R
"Dedicated Token Ring". The extract comprises the MIB for the Dedicated
Token Ring Concentrator, in SNMPv2 format.
802.5R is a standard that encompasses the existing 802.5 token-passing
method of operation, and also defines a new duplex method of operation
for use only on dedicated point to point links, that does not use tokens
for data transmission.
The architecture of a DTR Concentrator is defined in the 802.5R standard.
It is a MAC layer bridging device, which uses a new set of forwarding rules
that ease interoperability between source routing and transparent bridging
in an 802.5 LAN. The DTR Concentrator MIB is derived from the Source
Routing and Transparent Bridge MIBs (RFCs 1525 and 1493).
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-warwick-tokenring-arch-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-warwick-tokenring-arch-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-warwick-tokenring-arch-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960808094729.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-warwick-tokenring-arch-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-warwick-tokenring-arch-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960808094729.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa14365; 9 Aug 96 12:03 EDT
Received: from zephyr.isi.edu by ietf.org id aa14162; 9 Aug 96 11:51 EDT
Received: from akamai-a.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA27922>; Fri, 9 Aug 1996 08:51:46 -0700
Message-Id: <199608091551.AA27922 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1975 on PPP Magnalink Variable Resource Compression
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 09 Aug 96 08:54:25 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1975:
Title: PPP Magnalink Variable Resource Compression
Author: D. Schremp, J. Black & J. Weiss
Date: August 1996
Mailbox: dhs at magna.telco.com, jtb at magna.telco.com,
jaw at magna.telco.com
Pages: 6
Characters: 8,655
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1975.txt
The Point-to-Point Protocol (PPP) provides a standard method of
encapsulating multiple protocol datagrams over point-to-point links.
The PPP Compression Control Protocol provides a method for negotiating
data compression over PPP links. The Magnalink Variable Resource
Compression Algorithm (MVRCA) allows a wide range of interoperable
compression implementations whose performance characteristics are a
function of available CPU and memory resources. This RFC is the
product of the Point-to-Point Protocol Extensions Working Group of the
IETF.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <960809085240.RFC at ISI.EDU>
SEND /rfc/rfc1975.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1975.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960809085240.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16015; 9 Aug 96 13:16 EDT
Received: from aragorn.alternic.net by ietf.org id aa15822; 9 Aug 96 13:13 EDT
Received: (from ekashp at localhost) by aragorn.alternic.net (8.6.12/8.6.6) id KAA17349; Fri, 9 Aug 1996 10:11:37 -0700
Date: Fri, 9 Aug 1996 10:11:36 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Eugene Kashpureff <ekashp at alternic.net>
To: Mark Lottor <mkl at nw.com>
cc: ietf at ietf.org
Subject: Re: Internet Domain Survey, July 1996
In-Reply-To: <CMM.0.90.4.839548871.mkl at nw.com>
Message-ID: <Pine.LNX.3.91.960809100924.17273F at aragorn.alternic.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Thu, 8 Aug 1996, Mark Lottor wrote:
> Internet Domain Survey Network Wizards July 1996
>
> The Domain Survey attempts to discover every host on the Internet by doing
> a complete search of the Domain Name System. The latest results were
> gathered during late July 1996 and a summary is listed below.
You seem to have missed the ALTERNIC.NET TLDs ... a count would have been
usefull, to see just how unpopular we are .
At your name service,
Eugene Kashpureff, ALTERNIC.NET
Received: from ietf.org by ietf.org id aa16772; 9 Aug 96 13:33 EDT
Received: from fnal.fnal.gov by ietf.org id aa16697; 9 Aug 96 13:32 EDT
Received: from munin.fnal.gov ("port 1948"@munin.fnal.gov)
by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I82LSRXWWC001MU3 at FNAL.FNAL.GOV>;
Fri, 09 Aug 1996 12:32:30 -0600 (CST)
Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m)
id MAA13552; Fri, 09 Aug 1996 12:30:50 -0500 (CDT)
Date: Fri, 09 Aug 1996 12:30:50 -0500
Sender:ietf-request at ietf.org
From: Matt Crawford <crawdad at fnal.gov>
Subject: Re: Internet Domain Survey, July 1996
In-reply-to: "09 Aug 1996 10:11:36 PDT."
<"Pine.LNX.3.91.960809100924.17273F"@aragorn.alternic.net>
X-Orig-Sender: crawdad at munin.fnal.gov
To: Eugene Kashpureff <ekashp at alternic.net>
Cc: Mark Lottor <mkl at nw.com>, ietf at ietf.org
Message-id: <199608091730.MAA13552 at munin.fnal.gov>
Content-transfer-encoding: 7BIT
X-Face:
/RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$! at A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{<k&QF?d6L7o&zLqb%kXn!!]ykXMKtTiy9#20]$EKP/^Z$T]'P6,
8L#r&mH4PB<ljN,_.=iCpv#N:HIcy5t7{HV:<=g=V?^;-d,J*xkq0r
Source-Info: From (or Sender) name not authenticated.
> You seem to have missed the ALTERNIC.NET TLDs ... a count would have been
> usefull, to see just how unpopular we are .
> Eugene Kashpureff, ALTERNIC.NET
He was searching the *internet* namespace. Not BITNET, DECNET, UUCP,
trademarks, geography, Linnean taxonomy or any other random namespace.
Received: from ietf.org by ietf.org id aa17328; 9 Aug 96 13:42 EDT
Received: from zephyr.isi.edu by ietf.org id aa17078; 9 Aug 96 13:38 EDT
Received: from akamai-a.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA06657>; Fri, 9 Aug 1996 10:38:16 -0700
Message-Id: <199608091738.AA06657 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1977 on PPP BSD Compress
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 09 Aug 96 10:40:56 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1977:
Title: PPP BSD Compression Protocol
Author: V. Schryver
Date: August 1996
Mailbox: vjs at rhyolite.com
Pages: 25
Characters: 50,747
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1977.txt
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links. The
PPP Compression Control Protocol provides a method to negotiate and
utilize compression protocols over PPP encapsulated links. This
document describes the use of the Unix Compress compression protocol
for compressing PPP encapsulated packets. This RFC is the product of
the Point-to-Point Protocol Extensions Working Group of the IETF.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <960809103735.RFC at ISI.EDU>
SEND /rfc/rfc1977.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1977.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960809103735.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17531; 9 Aug 96 13:44 EDT
Received: from zephyr.isi.edu by ietf.org id aa17236; 9 Aug 96 13:42 EDT
Received: from akamai-a.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA06886>; Fri, 9 Aug 1996 10:42:03 -0700
Message-Id: <199608091742.AA06886 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1979 on PPP Deflate
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 09 Aug 96 10:44:43 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1979:
Title: PPP Deflate Protocol
Author: J. Woods
Date: August 1996
Mailbox: jfw at funhouse.com
Pages: 10
Characters: 18,803
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1979.txt
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links. The
PPP Compression Control Protocol provides a method to negotiate and
utilize compression protocols over PPP encapsulated links. This
document describes the use of the PPP Deflate compression protocol for
compressing PPP encapsulated packets. This RFC is the product of the
Point-to-Point Extensions Working Group of the IETF.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <960809104201.RFC at ISI.EDU>
SEND /rfc/rfc1979.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1979.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960809104201.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18951; 9 Aug 96 14:15 EDT
Received: from jekyll.piermont.com by ietf.org id aa18880; 9 Aug 96 14:13 EDT
Received: from localhost (perry at localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id OAA04826; Fri, 9 Aug 1996 14:13:10 -0400 (EDT)
Message-Id: <199608091813.OAA04826 at jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry at localhost didn't use HELO protocol
To: ietf at ietf.org
cc: Mark Lottor <mkl at nw.com>, Eugene Kashpureff <ekashp at alternic.net>
Subject: Re: Internet Domain Survey, July 1996
In-reply-to: Your message of "Fri, 09 Aug 1996 10:11:36 PDT."
<Pine.LNX.3.91.960809100924.17273F at aragorn.alternic.net>
Reply-To: perry at piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 09 Aug 1996 14:13:05 -0400
Sender:ietf-request at ietf.org
From: "Perry E. Metzger" <perry at piermont.com>
Source-Info: From (or Sender) name not authenticated.
Eugene Kashpureff writes:
> On Thu, 8 Aug 1996, Mark Lottor wrote:
>
> > Internet Domain Survey Network Wizards July 1996
> >
> > The Domain Survey attempts to discover every host on the Internet by doing
> > a complete search of the Domain Name System. The latest results were
> > gathered during late July 1996 and a summary is listed below.
>
> You seem to have missed the ALTERNIC.NET TLDs ... a count would have been
> usefull, to see just how unpopular we are .
For those not in the know, Eugene happily sells people top level
domains for something like $1500 -- of course, they don't work
anywhere (well, thats not true -- there are something like thirty DNS
servers in the world that know about them -- almost all owned by
people who bought TLDs from Eugene).
Its one thing to be running a scam, Eugene, and its another thing to
ask for Mark Lottor to stamp it as though it had some reality. Back
where I come from, thats referred to as "chutzpah".
Perry
Received: from ietf.org by ietf.org id aa21186; 9 Aug 96 15:46 EDT
Received: from nic.near.net by ietf.org id aa21095; 9 Aug 96 15:42 EDT
Received: from jcurran.bbnplanet.com by nic.near.net id aa27910;
9 Aug 96 15:42 EDT
X-Sender: jcurran at 198.114.157.116
Message-Id: <v02140b08ae3138b5d989 at [199.94.220.15]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Phone: (617) 873-4398
USMail: 150 CambridgePark Drive, Cambridge, MA, 02140
Date: Fri, 9 Aug 1996 15:42:12 -0400
To: Eugene Kashpureff <ekashp at alternic.net>
Sender:ietf-request at ietf.org
From: John Curran <jcurran at bbnplanet.com>
Subject: Re: Internet Domain Survey, July 1996
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 13:11 8/9/96, Eugene Kashpureff wrote:
>On Thu, 8 Aug 1996, Mark Lottor wrote:
>
>> Internet Domain Survey Network Wizards July 1996
>>
>> The Domain Survey attempts to discover every host on the Internet by doing
>> a complete search of the Domain Name System. The latest results were
>> gathered during late July 1996 and a summary is listed below.
>
>You seem to have missed the ALTERNIC.NET TLDs
If/when there are additional Internet TLD's, then
it would be appropriate to survey them. Until then,
you're just asking Mark to inject noise into the data...
/John
Received: from ietf.org by ietf.org id aa21768; 9 Aug 96 16:07 EDT
Received: from antares.aero.org by ietf.org id aa21714; 9 Aug 96 16:06 EDT
Received: from anpiel.aero.org (anpiel.aero.org [130.221.196.66]) by antares.aero.org (8.7.5/8.7.3) with SMTP id NAA27306 for <ietf at ietf.org>; Fri, 9 Aug 1996 13:06:15 -0700 (PDT)
Message-Id: <199608092006.NAA27306 at antares.aero.org>
To: ietf at ietf.org
Subject: What to do when a BIG ISP decides to break the rules?
Date: Fri, 09 Aug 1996 13:06:12 -0700
Sender:ietf-request at ietf.org
From: Mike O'Brien <obrien at antares.aero.org>
Source-Info: From (or Sender) name not authenticated.
Phil Agre at UCSD is known to many, I think. Fewer may know James
Armstrong, but he's been around forever. Here's a problem that even the
old ARPANET didn't solve satisfactorily (they had a problem with MULTICS) -
what to do when a major player announces that they are deliberately
planning to be nasty?
------- Forwarded Message
Date:Thu, 8 Aug 1996 18:16:31 -0700
From: Phil Agre <pagre at weber.ucsd.edu>
Message-Id: <199608090116.SAA22512 at weber.ucsd.edu>
To: rre at weber.ucsd.edu
Subject: Compuserve
Resent-Message-ID: <"Vji62D.A.7fF.xFpCy"@weber>
Resent-From: rre at weber.ucsd.edu
Reply-To: rre-maintainers at weber.ucsd.edu
Resent-Sender: rre-request at weber.ucsd.edu
[Having maintained a mailing list or two myself, I can attest that the bug
he's complaining about is just about the worst thing that a mailer can do.]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This message was forwarded through the Red Rock Eater News Service (RRE).
Send any replies to the original author, listed in the From: field below.
You are welcome to send the message along to others but please do not use
the "redirect" command. For information on RRE, including instructions
for (un)subscribing, send an empty message to rre-help at weber.ucsd.edu
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
From:IN%"james at sagarmatha.com" 4-AUG-1996 16:19:12.10
Subj:Reply from Compuserve
A while back, I mentioned that I was forced to move Compuserve
subscribers on my mailing lists to digest format because of Compuserve's
lack of adherence to accepted Internet standards. Although this did
upset several of my subscribers, I felt it was a necessary thing
to do (as have several other list managers here).
My complaints to Compuserve had gone unanswered. One of my subscribers
took it upon himself to make an inquery on his own. (I've asked him if
he still has the original of his query.) I sent him a short writeup
of my view of the problem, which I will repeat here:
:> Basically, the problem is that Compuserve and Wow mis-use the return
:> addressing information that accompanies an email message. Each
:> messgae has several addresses:
:>
:> FromUsed as an envelope address, error messages should be sent here.
:> From:The address of the original sender. Used for content-based
:> replies, unless Reply-To: is set.
:> Reply-To:The address for content-based replies.
:> Sender:Used as a reference if mail is forwarded.
:>
:> When someone sends a message to a mailing list, it should have the
:> header changed as follows:
:>
:> From gets set to the mailing list administrative address.
:> From: is unchanged.
:> Reply-To: is set to the address of the mailing list.
:> Sender: is changed to the administrative address.
:>
:> When a message encounters a problem, the error message should be sent
:> to the From or Sender: addresses, these are administrative messages.
:> Instead, Compuserve (and wow, which is owned by Compuserve) uses the
:> Reply-To: address.
:>
:> Fortunately, I've configured the mailing lists so that only members of
:> the lists can post. This means that the error messages are rejected,
:> but they then fill my mailbox.
:>
:> If the list were configured so that anyone could post, you then have
:> the classical mail-bomb situation. If a message is posted, and a
:> compuserve address has a problem, it sends a message to the list,
:> which is then forwarded to everybody, including the problem address.
:> This error message then generates another error message, and so on.
:> If more than one address has a problem, this then explodes
:> geometrically, eventually filling everybody's mailboxes with
:> Compuserve error messages.
:>
:> Several mailing list administrators have taken to either excluding
:> subscribers from compuserve, or moving them to digests only. I've
:> taken the latter step, although I don't like it.
Gordon Lamb received an answer from a CompuServe administrator recently,
that he forwarded to me today. In it, the administrator indicates that
it is Compuserve's policy to discourage Compuserve members from
joining Internet mailing lists, furthermore, even though their
software is causing a tremendous annoyance to Internet mailing list
administrators throughout the globe, they have absolutely no intention
of changing their software.
I enclose a copy of their response:
According to unnamed sources, Gordon Lamb is alleged to have written
=> Subj: WinCIM Internal EditorSection: CompuServe Software
=> From: Bob Parsons [Sysop], 111111,2433#24056
=> To: Gordon Lamb, 100272,354101 August 1996 11:52:17
=>
=> Hi Gordon,
=>
=> We do not encourage mailing lists I am afraid as they tend to encourage junk
=> mail and therefore we have no plans to make changes to our system in the way you
=> mention.
=>
=> Sorry!
=>
=> Regards,
=>
=> Bob
Gordon has informed me that he is looking to change ISP's as a result
of this.
I intend to invoke a permanent ban on compuserve subscriptions within
the next month (to allow those subscribers to change ISPs). I also
intend to publish this response in the news.net-abuse newsgroups.
[...]
If any other list administrators are equally so inclined, please
drop me a note, and I'll add your support to my efforts.
- --
James C. Armstrong, Jr. | It's time to taste what you most fear
james at sagarmatha.com (home) | Right Guard will not help you here.
| Brace yourself, my dear!
| It's a holiday in Cambodia!
------- End of Forwarded Message
Received: from ietf.org by ietf.org id aa25465; 9 Aug 96 19:13 EDT
Received: from nic.near.net by ietf.org id aa25295; 9 Aug 96 19:04 EDT
Received: from jcurran.bbnplanet.com by nic.near.net id aa02692;
9 Aug 96 19:03 EDT
X-Sender: jcurran at 198.114.157.116
Message-Id: <v02140b00ae3170186744 at [199.94.220.15]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Phone: (617) 873-4398
USMail: 150 CambridgePark Drive, Cambridge, MA, 02140
Date: Fri, 9 Aug 1996 19:03:44 -0400
To: Mike O'Brien <obrien at antares.aero.org>
Sender:ietf-request at ietf.org
From: John Curran <jcurran at bbnplanet.com>
Subject: Re: What to do when a BIG ISP decides to break the rules?
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 16:06 8/9/96, Mike O'Brien wrote:
>...
>what to do when a major player announces that they are deliberately
>planning to be nasty?
Hello Mike!
Using the "reply-to" field for delivery errors is definitely a major
pain, and it's worth fighting to get it fixed. I'm not certain that I'd
put total faith into one reply from a sysop; I would aim for their
Internet-literate staff (e.g. IETF attendees) and/or their marketing
folks and try to explain the problem. If it turns out that you still get
the same answer, then we can either escalate into an onsite visit by
an appropriate Internet emissary or you take it directly to the 'net
with a grassroots campaign of list moderation, etc.
/John
p.s. Frankly, I'd rather launch the grassroot campaign after a good faith
effort to resolve things, but that's potentially a minority opinion on
today's militant Internet...
Received: from ietf.org by ietf.org id aa25563; 9 Aug 96 19:16 EDT
Received: from cnri by ietf.org id aa25559; 9 Aug 96 19:16 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15729;
9 Aug 96 19:16 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <WAA05011 at pad-thai.cam.ov.com>; Fri, 9 Aug 1996 22:49:34 GMT
Received: from PO10.ANDREW.CMU.EDU by MIT.EDU with SMTP
id AA02971; Fri, 9 Aug 96 18:49:26 EDT
Received: (from postman at localhost) by po10.andrew.cmu.edu (8.7.5/8.7.3) id SAA00991 for cat-ietf at mit.edu; Fri, 9 Aug 1996 18:49:22 -0400
Received: via switchmail; Fri, 9 Aug 1996 18:49:21 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.Ym2w0Na00WBw00ue40>;
Fri, 9 Aug 1996 18:47:53 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr7/jgm/.Outgoing/QF.cm2w0MG00WBw0e4YM0>;
Fri, 9 Aug 1996 18:47:52 -0400 (EDT)
Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.54
via MS.5.6.hogtown.andrew.cmu.edu.sun4_51;
Fri, 9 Aug 1996 18:47:50 -0400 (EDT)
Message-Id: <Um2w0KS00WBw0e4YA0 at andrew.cmu.edu>
Date: Fri, 9 Aug 1996 18:47:50 -0400 (EDT)
Sender:ietf-archive-request at ietf.org
From: John Gardiner Myers <jgm at cmu.edu>
To: cat-ietf at mit.edu
Subject: Re: CAT WG Review Last-Call: draft-myers-auth-sasl-04.txt
In-Reply-To: <9608070025.AA15460 at dcl.MIT.EDU>
References: <9608070025.AA15460 at dcl.MIT.EDU>
> It may be perhaps be the text in the MIME registration, but it would
> make more sense to require that the IANA maintain a registry of whoever
> is the current contact point for a particular mechanism, so that people
> could contact the mechanism owner directly, instead of requiring the
> IANA to forward comments. This indirect approach seems somewhat silly.
I think the point of the "comment" part of the IANA registry is to
cover the case where someone registers a mechanism that is a Bad Idea.
For example, one which is subject to a particular method of attack.
The important part in my mind is to allow the IANA at its discretion
to attach comments when so requested. Perhaps I should remove the
option of submitting a comment, but not requesting it be attached?
If you seriously don't like the idea of the IANA being a "comment
clearinghouse", you may want to raise this issue with the IESG in the
context of the MIME registration document.
> Also, instead of making it optional for there to be an informational
> RFC, I think it should be made mandatory. This seems fair; if the IANA
> is going to register it in a public namespace, there should be a public
> definition of what the IANA is actually registering.
I absolutely disagree. The IANA currently assigns well known ports, a
resource far more scarce than SASL mechanism names, to proprietary,
unpublished protocols. Last time I checked, the IANA port
registration document even offered to go NDA to collect information
for evaluating the request.
Publishing protocols is to be strongly encouraged, but we do not
achieve our goal of interoperability by attempting to mandate it.
> If someone wants
> to do something proprietary, it should be using some sort of
> experimental prefix (e.g., X-MACROHARD-UNREGISTERED-PROPRIETARY-STANDARD.)
The problem with this approach, as has been demonstrated by ESMTP, is
that it prevents such experimental or proprietary protocols from later
entering the standards track without the disruption to the installed
base of a name change.
Registration and standardization are orthogonal procedures. The first
is required in order to prevent namespace collisions. The second is
merely the most effective way to get interoperability.
--
_.John Gardiner MyersInternet: jgm+ at CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
Received: from ietf.org by ietf.org id aa28811; 9 Aug 96 22:53 EDT
Received: from ZAFU.BBN.COM by ietf.org id aa28734; 9 Aug 96 22:50 EDT
Received: from localhost (day at localhost) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id WAA20147; Fri, 9 Aug 1996 22:55:35 -0400 (EDT)
Message-Id: <199608100255.WAA20147 at zafu.bbn.com>
X-Authentication-Warning: zafu.bbn.com: Host day at localhost didn't use HELO protocol
Sender:ietf-request at ietf.org
From: John Day <day at bbn.com>
Subject: Re: What to do when a BIG ISP decides to break the rules?
To: obrien at antares.aero.org
Cc: ietf at ietf.org
In-Reply-To: <199608092006.NAA27306 at antares.aero.org>
Date: Fri, 9 Aug 96 22:13:28 EDT
Mail-System-Version: <BBN/MacEMail_v1.6 at BBN.COM>
Source-Info: From (or Sender) name not authenticated.
Given Compuserve's attitude, one could conclude that they are protecting
their users from junk mail and therefore have taken it upon themselves
to be responsible for the content of messages on their net, more like a
newspaper than a carrier. Now that opens up all sorts of other problems
for Compuserve.
Gee, you would have thought they had learned about such things.
>
> Phil Agre at UCSD is known to many, I think. Fewer may know James
>Armstrong, but he's been around forever. Here's a problem that even the
>old ARPANET didn't solve satisfactorily (they had a problem with MULTICS) -
>what to do when a major player announces that they are deliberately
>planning to be nasty?
>
>------- Forwarded Message
>
>Date:Thu, 8 Aug 1996 18:16:31 -0700
>From: Phil Agre <pagre at weber.ucsd.edu>
>Message-Id: <199608090116.SAA22512 at weber.ucsd.edu>
>To: rre at weber.ucsd.edu
>Subject: Compuserve
>Resent-Message-ID: <"Vji62D.A.7fF.xFpCy"@weber>
>Resent-From: rre at weber.ucsd.edu
>Reply-To: rre-maintainers at weber.ucsd.edu
>Resent-Sender: rre-request at weber.ucsd.edu
>
>[Having maintained a mailing list or two myself, I can attest that the bug
>he's complaining about is just about the worst thing that a mailer can do.]
>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>This message was forwarded through the Red Rock Eater News Service (RRE).
>Send any replies to the original author, listed in the From: field below.
>You are welcome to send the message along to others but please do not use
>the "redirect" command. For information on RRE, including instructions
>for (un)subscribing, send an empty message to rre-help at weber.ucsd.edu
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
>From:IN%"james at sagarmatha.com" 4-AUG-1996 16:19:12.10
>Subj:Reply from Compuserve
>
>A while back, I mentioned that I was forced to move Compuserve
>subscribers on my mailing lists to digest format because of Compuserve's
>lack of adherence to accepted Internet standards. Although this did
>upset several of my subscribers, I felt it was a necessary thing
>to do (as have several other list managers here).
>
>My complaints to Compuserve had gone unanswered. One of my subscribers
>took it upon himself to make an inquery on his own. (I've asked him if
>he still has the original of his query.) I sent him a short writeup
>of my view of the problem, which I will repeat here:
>
>:> Basically, the problem is that Compuserve and Wow mis-use the return
>:> addressing information that accompanies an email message. Each
>:> messgae has several addresses:
>:>
>:> FromUsed as an envelope address, error messages should be sent here.
>:> From:The address of the original sender. Used for content-based
>:> replies, unless Reply-To: is set.
>:> Reply-To:The address for content-based replies.
>:> Sender:Used as a reference if mail is forwarded.
>:>
>:> When someone sends a message to a mailing list, it should have the
>:> header changed as follows:
>:>
>:> From gets set to the mailing list administrative address.
>:> From: is unchanged.
>:> Reply-To: is set to the address of the mailing list.
>:> Sender: is changed to the administrative address.
>:>
>:> When a message encounters a problem, the error message should be sent
>:> to the From or Sender: addresses, these are administrative messages.
>:> Instead, Compuserve (and wow, which is owned by Compuserve) uses the
>:> Reply-To: address.
>:>
>:> Fortunately, I've configured the mailing lists so that only members of
>:> the lists can post. This means that the error messages are rejected,
>:> but they then fill my mailbox.
>:>
>:> If the list were configured so that anyone could post, you then have
>:> the classical mail-bomb situation. If a message is posted, and a
>:> compuserve address has a problem, it sends a message to the list,
>:> which is then forwarded to everybody, including the problem address.
>:> This error message then generates another error message, and so on.
>:> If more than one address has a problem, this then explodes
>:> geometrically, eventually filling everybody's mailboxes with
>:> Compuserve error messages.
>:>
>:> Several mailing list administrators have taken to either excluding
>:> subscribers from compuserve, or moving them to digests only. I've
>:> taken the latter step, although I don't like it.
>
>Gordon Lamb received an answer from a CompuServe administrator recently,
>that he forwarded to me today. In it, the administrator indicates that
>it is Compuserve's policy to discourage Compuserve members from
>joining Internet mailing lists, furthermore, even though their
>software is causing a tremendous annoyance to Internet mailing list
>administrators throughout the globe, they have absolutely no intention
>of changing their software.
>
>I enclose a copy of their response:
>
>According to unnamed sources, Gordon Lamb is alleged to have written
>=> Subj: WinCIM Internal EditorSection: CompuServe Software
>=> From: Bob Parsons [Sysop], 111111,2433#24056
>=> To: Gordon Lamb, 100272,354101 August 1996 11:52:17
>=>
>=> Hi Gordon,
>=>
>=> We do not encourage mailing lists I am afraid as they tend to encourage junk
>=> mail and therefore we have no plans to make changes to our system in the way you
>=> mention.
>=>
>=> Sorry!
>=>
>=> Regards,
>=>
>=> Bob
>
>Gordon has informed me that he is looking to change ISP's as a result
>of this.
>
>I intend to invoke a permanent ban on compuserve subscriptions within
>the next month (to allow those subscribers to change ISPs). I also
>intend to publish this response in the news.net-abuse newsgroups.
>[...]
>
>If any other list administrators are equally so inclined, please
>drop me a note, and I'll add your support to my efforts.
>- --
>James C. Armstrong, Jr. | It's time to taste what you most fear
>james at sagarmatha.com (home) | Right Guard will not help you here.
> | Brace yourself, my dear!
> | It's a holiday in Cambodia!
>
>
>------- End of Forwarded Message
>
>
Received: from ietf.org by ietf.org id aa11397; 10 Aug 96 11:54 EDT
Received: from cnri by ietf.org id aa11393; 10 Aug 96 11:54 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa07417;
10 Aug 96 11:54 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <OAA25434 at pad-thai.cam.ov.com>; Sat, 10 Aug 1996 14:20:40 GMT
Received: from PO10.ANDREW.CMU.EDU by MIT.EDU with SMTP
id AA15435; Sat, 10 Aug 96 10:20:39 EDT
Received: (from postman at localhost) by po10.andrew.cmu.edu (8.7.5/8.7.3) id KAA00564 for cat-ietf at mit.edu; Sat, 10 Aug 1996 10:20:36 -0400
Received: via switchmail; Sat, 10 Aug 1996 10:20:35 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.om39e1y00WBw00ue80>;
Sat, 10 Aug 1996 10:19:46 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr7/jgm/.Outgoing/QF.0m39e0y00WBw0eZ0I0>;
Sat, 10 Aug 1996 10:19:45 -0400 (EDT)
Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.54
via MS.5.6.hogtown.andrew.cmu.edu.sun4_51;
Sat, 10 Aug 1996 10:19:43 -0400 (EDT)
Message-Id: <Em39dzS00WBw0eZ080 at andrew.cmu.edu>
Date: Sat, 10 Aug 1996 10:19:43 -0400 (EDT)
Sender:ietf-archive-request at ietf.org
From: John Gardiner Myers <jgm at cmu.edu>
To: cat-ietf at mit.edu
Subject: SASL: on vacation
I had hoped to get SASL wrapped up in time for my vacation, but that
seems not to have happened. I will be away from e-mail for two weeks,
I will address the latest comments when I get back.
--
_.John Gardiner MyersInternet: jgm+ at CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
Received: from ietf.org by ietf.org id aa00490; 11 Aug 96 10:16 EDT
Received: from cnri by ietf.org id aa00297; 11 Aug 96 10:06 EDT
Received: from gw.home.vix.com by CNRI.Reston.VA.US id aa06052;
11 Aug 96 10:06 EDT
Received: by gw.home.vix.com id HAA00397; Sun, 11 Aug 1996 07:06:10 -0700 (PDT)
Date: Sun, 11 Aug 1996 07:06:10 -0700 (PDT)
X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us
To: ietf at CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: Paul A Vixie <paul at vix.com>
Subject: Re: Internet Domain Survey, July 1996
Organization: Vixie Enterprises
Message-ID: <VIXIE.96Aug11070607 at wisdom.vix.com>
References: <CMM.0.90.4.839548871.mkl at nw.com>
<Pine.LNX.3.91.960809100924.17273F at aragorn.alternic.net>
NNTP-Posting-Host: wisdom.home.vix.com
In-reply-to: ekashp at alternic.net's message of 9 Aug 1996 10:52:21 -0700
Source-Info: From (or Sender) name not authenticated.
> You seem to have missed the ALTERNIC.NET TLDs ... a count would have been
> usefull, to see just how unpopular we are .
And you missed .MARTIANS and .SAUCER-PEOPLE. Make sure you count *everything*.
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul at vix.com>
pacbell!vixie!paul
Received: from ietf.org by ietf.org id aa00616; 11 Aug 96 10:21 EDT
Received: from cnri by ietf.org id aa00557; 11 Aug 96 10:19 EDT
Received: from gw.home.vix.com by CNRI.Reston.VA.US id aa06177;
11 Aug 96 10:19 EDT
Received: by gw.home.vix.com id HAA00899; Sun, 11 Aug 1996 07:19:35 -0700 (PDT)
Date: Sun, 11 Aug 1996 07:19:35 -0700 (PDT)
X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us
To: ietf at CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: Paul A Vixie <paul at vix.com>
Subject: Re: What to do when a BIG ISP decides to break the rules?
Organization: Vixie Enterprises
Message-ID: <VIXIE.96Aug11071934 at wisdom.vix.com>
References: <v02140b00ae3170186744 at [199.94.220.15]>
NNTP-Posting-Host: wisdom.home.vix.com
In-reply-to: jcurran at bbnplanet.com's message of 9 Aug 1996 16:35:30 -0700
Source-Info: From (or Sender) name not authenticated.
> p.s. Frankly, I'd rather launch the grassroot campaign after a good faith
> effort to resolve things, but that's potentially a minority opinion on
> today's militant Internet...
That time is past. It's no longer safe to assume that someone is breaking
the rules out of ignorance or by accident. I've fought the Reply-To policy
of Compuserve for seven years, thought I didn't save their various replies.
Compuserve has their own internal forums and they view the Internet as "just
additional background traffic" for each of these. Five years ago when I
looked very closely at all this, the forum/mailinglist gateways were
unidirectional since Compuserve viewed the writings of its customers as
"added value" and saw no reason to gateway them, for free, back to the
Internet mailing list where some discussion may in fact have originated.
(Their customers seem to have pressured them into changing that policy.)
I also told them that my lists were somewhat private and that it was not
reasonable for them to gateway them into public forums inside Compuserve.
At this point I _always_ tell Compuserve customers that I'd be much happier
if they switched ISPs before I add them to any of my local mailing lists.
Compuserve's culture predates the wide market acceptance of the Internet,
and as such it's not easy to call their view of the world ``wrong.''
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul at vix.com>
pacbell!vixie!paul
Received: from ietf.org by ietf.org id aa08335; 11 Aug 96 21:55 EDT
Received: from stilton.cisco.com by ietf.org id aa08241; 11 Aug 96 21:50 EDT
Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.12/8.6.5) with SMTP id SAA01816; Sun, 11 Aug 1996 18:49:57 -0700
X-Sender: fred at stilton.cisco.com
Message-Id: <v02140b05ae315e448bcf at [171.69.128.114]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 11 Aug 1996 18:48:59 -0700
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Fred Baker <fred at cisco.com>
Subject: Dvorak PC Telecommunications Excellence Award
Source-Info: From (or Sender) name not authenticated.
Five years ago, computer columnist and PC Telecommunications expert, John
C. Dvorak, established the Dvorak PC Telecommunications Excellence Awards
to recognize the people, organizations, companies, products, and services
that have contributed to the growth and advancement of PC
Telecommunications and the Internet.
It was my honor and privilege to accept one of these awards on behalf of
the IETF Saturday evening. Dr. Dvorak is recognizing the IETF as an
organization - a volunteer organization - which has changed the world in
which we live. A reporter asked me not long ago whether I had ever expected
a commercial internet to operate. "Yes," I answered, "that didn't surprise
me. Finding URLs in lipstick advertisements really threw me though." And
attending a Bible Study the other evening, I was somewhat floored to find
the first order of discussion to be: "why did my internet provider go off
line for 10 hours today?"
This gives us an opportunity to reflect on all the things that are working
right, the things that volunteers - we and out colleagues - have spent time
and done for the good of us all and millions who have no idea what we do.
And it gives us the opportunity feel good about that.
I will have the actual award on display at the San Jose IETF meeting.
Congratulations!
Fred Baker
_______________________________________________________________________
3. Outstanding Volunteer
Internet Organization
Internet Engineering Task Force (IETF)
Accepting the award: Fred Baker, Cisco, IETF/IESG Chair
The Internet Engineering Task Force (IETF) is the protocol engineering and
development arm of the Internet. It's responsible for setting standards,
so that everyone on the Internet uses the same protocols and conventions.
Without the IETF, the Internet would disintegrate into different factions
that cannot communicate with each other so much the way some partisans
believe the many independent HTML "extensions" among warring Web browsers
have done to the World Wide Web.
IETF standards do not carry the force of law - no standards body does, in
the Internet's wide-open, international venue. Rather, it is a large, open
international community of network designers, operators, vendors, and
researchers concerned with the evolving Internet architecture and the
smooth operation of the Internet. It is open to any interested individual,
though naturally people who are technically or professionally involved with
the Internet make up the majority of members.
The IETF's actual technical work is done in working groups organized by
topic into various areas like routing, network management, security, and so
forth. Members keep in touch by mailing lists, which allows rapid and
widespread cross-pollination of ideas between members. Three times a year,
the IETF also holds physical meetings.
IETF Secretariat, Steve Coya
c/o Corporation for National Research Initiatives
1895 Preston White Drive, Suite 100
Reston, VA 22091
Tel: 703 620-8990 Fax: 703-758-5913
IETF Executive Director, Steve Coya, scoya at cnri.reston.va.us
IETF/IESG Chai, Fred Baker, fred at cisco.com, Tel: 408-526-4257,
Fax: 805-681-0115
E-Mail: ietf-info at ietf.org, URL: http://www.ietf.ietf.org/home.html
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I don't suffer from insanity. I enjoy every minute of it.
Received: from ietf.org by ietf.org id aa17516; 12 Aug 96 2:05 EDT
Received: from pinky.junction.net by ietf.org id aa17427; 12 Aug 96 2:02 EDT
Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id WAA29497; Sun, 11 Aug 1996 22:14:51 -0700
Received: from localhost (michael at localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id WAA05462; Sun, 11 Aug 1996 22:58:37 -0700
Date: Sun, 11 Aug 1996 22:58:36 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Michael Dillon <michael at memra.com>
To: piara at apnic.net
Subject: State of the Art regarding PIARA
In-Reply-To: <01BB83B2.FF2BD2A0 at webster.unety.net>
Message-ID: <Pine.BSI.3.93.960811223545.3974M-100000 at sidhe.memra.com>
Organization: Memra Software Inc. - Internet consulting
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
> Operations-folks, we have to make the PIARA experiment work. Else it is
> forever and always arguing over what Randy/David and Mark et al are up to.
>
> Let's make the BCP argument moot -- let the market decide. We need open
> iTLDs and PIARA.
First, IMHO, open iTLD's and PIARA are very, very different things. It is
a mere accident of history that Kim Hubbard works for the organization
which registers .COM, .NET, etc... domain names.
I just got back from San Francisco (ONE ISPCON) where I suggested that
there is some state of the art stuff that PIARA folks *NEED* to look at to
understand the scope of the problem. Since you weren't all there I will
tell you now. Perhaps it was mentioned at the BOF but I find no mention on
the PIARA mailing list.
Context
-------
Bill Manning is making a presentation re IP allocation policies and
procedures. Some people start making comments about selling integers (or
longs). I feel there is some misunderstanding here so I said something
like the following.
Nobody is suggesting that integers or IP numbers be sold. This implies
that they are things but they are not things. The whole discussion
revolves around selling *RIGHTS* not numbers. The right to use the number
on the global Internet is the valuable commodity here. Well, it appears
that there have been situations in the past where "rights" have become a
commodity and I think you need to study these before drafting any
policies.
In particular, many Canadian provinces have one or more marketing boards
that control the production of a specific product such as milk. The
Ontario Milk Marketing Board sets production quotas as to how much total
milk may be produced in the province. At the time the board was formed
(over 20 years ago, I believe) the quota was subdivided and allocated to
farmers. But what if a farmer has enough land to support more cows and
therefore wants to produce more milk?
Answer. He must obtain quota first. Thus was born the market for milk
quota. Farmers now buy and sell quota, often for extremely high prices.
Once they own the quota, they have nothing more substantive than a "right"
to produce milk. They must still buy or raise the cows, buy or grow the
feed, etc, etc.
PIARA must study the experience of Canada's agricultural marketing boards
to see what can happen in a system in which "rights" are given monetary
value. You can find some info on Altavista, but I think to really
understand it you would need to have access to a physical library (i.e.
stacks of paper on wood or metal shelves in a quiet carpeted room).
Anyway, you would need to look into back issues of various Canadian
magazines and newspapers, particularily in Ontario.
Newspapers include the Globe and Mail, Toronto Daily Star, Toronto Sun.
Magazines include Maclean's, Harrowsmith.
Of course there is SOME info on the web like the Milk Quota Exchange at
http://www.milk.org/quota.htm
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael at memra.com
Received: from ietf.org by ietf.org id aa24196; 12 Aug 96 9:31 EDT
Received: from callandor.cybercash.com by ietf.org id aa24029;
12 Aug 96 9:23 EDT
Received: by callandor.cybercash.com; id JAA19801; Mon, 12 Aug 1996 09:21:49 -0400
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (V3.1)
id xma019776; Mon, 12 Aug 96 09:21:32 -0400
Received: by cybercash.com (4.1/SMI-4.1)
id AA02259; Mon, 12 Aug 96 09:21:59 EDT
Date: Mon, 12 Aug 1996 09:21:58 -0400 (EDT)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: ietf at ietf.org
Subject: Re: What to do when a BIG ISP decides to break the rules?
In-Reply-To: <v02140b00ae3170186744 at [199.94.220.15]>
Message-Id: <Pine.SUN.3.91.960812083833.864A-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On thing the IETF does control is the IETF mailing list. It would be fairly
easy to come up with an auotated test tool to tell if a mail address handled
non-deliverable mail properly. One course of action would be to refuse to
put any address on the IETF list that has this problem, and make this
automated tool available to working groups, etc., and suggest they follow the
same policy. Certainly there are enough service providers that do conform to
the standards on major points like this that no one would have difficulty
getting an account they could then joing the IETF list from. This might
finally get some attention.
On Fri, 9 Aug 1996, John Curran wrote:
> Date: Fri, 9 Aug 1996 19:03:44 -0400
> From: John Curran <jcurran at bbnplanet.com>
> To: Mike O'Brien <obrien at antares.aero.org>
> Cc: ietf at ietf.org
> Subject: Re: What to do when a BIG ISP decides to break the rules?
>
> At 16:06 8/9/96, Mike O'Brien wrote:
> >...
> >what to do when a major player announces that they are deliberately
> >planning to be nasty?
>
> Hello Mike!
>
> Using the "reply-to" field for delivery errors is definitely a major
> pain, and it's worth fighting to get it fixed. I'm not certain that I'd
> put total faith into one reply from a sysop; I would aim for their
> Internet-literate staff (e.g. IETF attendees) and/or their marketing
> folks and try to explain the problem. If it turns out that you still get
> the same answer, then we can either escalate into an onsite visit by
> an appropriate Internet emissary or you take it directly to the 'net
> with a grassroots campaign of list moderation, etc.
This has been going on for so many years that I believe most likely
Compuserve has decided this is insignificant and never intends to fix
it. If I am wrong on this, perhaps they will post a correction.
> /John >
> p.s. Frankly, I'd rather launch the grassroot campaign after a good faith
> effort to resolve things, but that's potentially a minority opinion on
> today's militant Internet...
Donald
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from ietf.org by ietf.org id aa24799; 12 Aug 96 9:41 EDT
Received: from localhost by ietf.org id aa24630; 12 Aug 96 9:40 EDT
To: ietf at ietf.org
Subject: Re: Internet Domain Survey, July 1996
Sender:ietf-request at ietf.org
From: "Dale R. Worley" <worley at ariadne.com>
Date: Mon, 12 Aug 1996 09:40:27 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9608120940.aa24630 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
In article <Pine.LNX.3.91.960809100924.17273F at aragorn.alternic.net>
ekashp at alternic.net (Eugene Kashpureff) writes:
> The Domain Survey attempts to discover every host on the Internet by
doing
> a complete search of the Domain Name System. The latest results were
> gathered during late July 1996 and a summary is listed below.
You seem to have missed the ALTERNIC.NET TLDs ... a count would have been
usefull, to see just how unpopular we are .
Well, at first glance, it would seem that your "unpopularity" has been
exactly measured, at a count of 0 host names.
If and when "ALTERNIC.NET TLDs" become accepted as valid/useful in the
Internet custom, I suspect that they'll be counted in the Domain
Survey.
Dale
--
Dale R. Worley Ariadne Internet Services
Voice: +1 617-899-7949 Fax: +1 617-899-7946 E-mail: worley at ariadne.com
"Internet-based electronic commerce solutions to real business problems."
Received: from ietf.org by ietf.org id aa25106; 12 Aug 96 9:47 EDT
Received: from localhost by ietf.org id aa25038; 12 Aug 96 9:46 EDT
To: ietf at ietf.org
Subject: Re: What to do when a BIG ISP decides to break the rules?
Sender:ietf-request at ietf.org
From: Rahul Dhesi <dhesi at rahul.net>
Date: Mon, 12 Aug 1996 09:46:15 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9608120946.aa25038 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
In <VIXIE.96Aug11071934 at wisdom.vix.com> paul at vix.com (Paul A Vixie) writes:
>Compuserve has their own internal forums and they view the Internet as "just
>additional background traffic" for each of these....
...[In the past] Compuserve viewed the writings of its customers as
>"added value" and saw no reason to gateway them, for free, back to the
>Internet mailing list...
Note also that at least in the past, if not more recently, there were
reports on Usenet that compuServe and MCI mail had some sort of
arrangement such that any mail message found crossing the two services
via an outside path
mcimail address -> internet mailing list -> compuserve address
was dropped and not delivered. The same might have been true of mail
between two compuserve addresses that took the long path through an
Internet mailing list. Compuserve users used to complain that they
could not see all messages appearing in Internet mailing lists.
--
Rahul Dhesi <dhesi at rahul.net>
"please ignore Dhesi" -- Mark Crispin <mrc at CAC.Washington.EDU>
Received: from ietf.org by ietf.org id aa25272; 12 Aug 96 9:50 EDT
Received: from localhost by ietf.org id aa25182; 12 Aug 96 9:49 EDT
To: ietf at ietf.org
Subject: Re: What to do when a BIG ISP decides to break the rules?
Sender:ietf-request at ietf.org
From: "Dale R. Worley" <worley at ariadne.com>
Date: Mon, 12 Aug 1996 09:49:32 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9608120949.aa25182 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
In article <VIXIE.96Aug11071934 at wisdom.vix.com> paul at vix.com (Paul A Vixie)
writes:
At this point I _always_ tell Compuserve customers that I'd be much happier
if they switched ISPs before I add them to any of my local mailing lists.
Refuse to add Compuserve addresses to your mailing list. If a
significant number of mailing list operators adopt this policy, they
will pressure Compuserve to fix their system.
Dale
--
Dale R. Worley Ariadne Internet Services
Voice: +1 617-899-7949 Fax: +1 617-899-7946 E-mail: worley at ariadne.com
"Internet-based electronic commerce solutions to real business problems."
Received: from ietf.org by ietf.org id aa26385; 12 Aug 96 10:17 EDT
Received: from localhost by ietf.org id aa25597; 12 Aug 96 10:00 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ion at nexen.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ion-bcast-00.txt
Date: Mon, 12 Aug 1996 10:00:54 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608121000.aa25597 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internetworking Over NBMA
Working Group of the IETF.
Title : IP Broadcast over ATM Networks.
Author(s) : T. Smith, G. Armitage
Filename : draft-ietf-ion-bcast-00.txt
Pages : 13
Date : 08/09/1996
This memo describes how the IP multicast service being developed by the IP
over ATM working group may be used to support IP broadcast transmission.
The solution revolves around treating the broadcast problem as a special
case of multicast, where every host in the subnet or cluster is a member of
the group.
An understanding of the services provided by draft-ietf-ipatm-ipmc-12.txt
is assumed.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ion-bcast-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-bcast-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ion-bcast-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960809151717.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-bcast-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-bcast-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960809151717.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26387; 12 Aug 96 10:17 EDT
Received: from localhost by ietf.org id aa25859; 12 Aug 96 10:04 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgp at ans.net
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-idr-bgp4-03.txt
Date: Mon, 12 Aug 1996 10:04:19 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608121004.aa25859 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Inter-Domain Routing Working
Group of the IETF.
Title : A Border Gateway Protocol 4 (BGP-4)
Author(s) : Y. Rekhter, T. Li
Filename : draft-ietf-idr-bgp4-03.txt
Pages : 59
Date : 08/09/1996
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing
protocol. It is built on experience gained with EGP as defined in RFC 904
[1] and EGP usage in the NSFNET Backbone as described in RFC 1092 [2] and
RFC 1093 [3].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-idr-bgp4-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-03.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-idr-bgp4-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960812100250.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idr-bgp4-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960812100250.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26744; 12 Aug 96 10:23 EDT
Received: from copilot.is.chrysler.com by ietf.org id aa26436;
12 Aug 96 10:16 EDT
Received: by pilotx.firewall.is.chrysler.com; id KAA03877; Mon, 12 Aug 1996 10:16:18 -0400
Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilotx.is.chrysler.com via smap (g3.0.1)
id sma003872; Mon, 12 Aug 96 10:15:55 -0400
Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id KAA03413; Mon, 12 Aug 1996 10:08:38 -0400 (EDT)
Message-Id: <2.2.32.19960812141429.00bdd260 at pop3hub.is.chrysler.com>
X-Sender: rgm3 at pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 12 Aug 1996 10:14:29 -0400
To: Rahul Dhesi <dhesi at rahul.net>, ietf at ietf.org
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: What to do when a BIG ISP decides to break the rules?
Source-Info: From (or Sender) name not authenticated.
At 09:46 AM 8/12/96 -0400, Rahul Dhesi wrote:
>
>Note also that at least in the past, if not more recently, there were
>reports on Usenet that compuServe and MCI mail had some sort of
>arrangement such that any mail message found crossing the two services
>via an outside path
>
> mcimail address -> internet mailing list -> compuserve address
This is absolutely true, as I use to be an mcimail denizen. The opposite
direction was also true.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.org by ietf.org id aa29338; 12 Aug 96 11:16 EDT
Received: from ng.netgate.net by ietf.org id aa29217; 12 Aug 96 11:13 EDT
Received: from [205.214.160.39] (d69.netgate.net [205.214.160.105]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id IAA14128; Mon, 12 Aug 1996 08:18:27 -0700 (PDT)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v0300780fae34f6912309 at [205.214.160.39]>
In-Reply-To: <Pine.SUN.3.91.960812083833.864A-100000 at cybercash.com>
References: <v02140b00ae3170186744 at [199.94.220.15]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Mon, 12 Aug 1996 08:01:01 -0700
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Mailing List Standards (was: Re: What to do when a BIG ISP
decides to break the rules?)
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 6:21 AM -0700 8/12/96, Donald E. Eastlake 3rd wrote:
>non-deliverable mail properly. One course of action would be to refuse to
>put any address on the IETF list that has this problem, and make this
>automated tool available to working groups, etc., and suggest they follow the
>same policy. Certainly there are enough service providers that do conform to
Don, the really important part of your suggestion is formulation of
some Internet standard mailing list practises. Once we do that, lots of
distribution list software will implement it.
There have been one or two abortive distribution list working group
efforts. I think the usual view is that they died from being too ambitious
(though I've also heard that lack of responsiveness on the part of one of
the core authors of software might have been a contributing factor.)
As happens, the world has changed.
Perhaps there is more of a change to get agreement about a core set
of core issues to solve. There certainly is a larger set of software in
use and there is a different package in dominant use now.
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from ietf.org by ietf.org id aa29937; 12 Aug 96 11:32 EDT
Received: from localhost by ietf.org id aa29760; 12 Aug 96 11:25 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: srv-location at tgv.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Service Location Protocol to Proposed Standard
Date: Mon, 12 Aug 1996 11:25:34 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9608121125.aa29760 at ietf.org>
The IESG has approved the Internet-Draft "Service Location Protocol"
<draft-ietf-svrloc-protocol-14.txt> as a Proposed Standard. This
document is the product of the Service Location Protocol Working
Group. The IESG contact persons are Frank Kastenholz and Jeffrey
Burgan.
Technical Summary
The service location protocol provides a faremwork for registration,
discovery, and selection of network services in relatively
constrained topologies. It allows clients (i.e. those seeking to use
a particular service) to form queries for services that include
specific attributes of the desired service (eg, "I want a printer
with purple paper and pink printing").
Working Group Summary
This protocol is a product of the service location working group and
is a result of the merging of two different approaches that the
working group considered. There has been no dissent in the working
group. There are at least 5 efforts underway to implement the
protocol.
Protocol Quality
This protocol has been reviewed for the IESG by Frank Kastenholz and
Jeff Burgan, Internet Area Co-Directors.
Received: from ietf.org by ietf.org id aa00093; 12 Aug 96 11:36 EDT
Received: from localhost by ietf.org id aa00014; 12 Aug 96 11:33 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: The PPP SNA Control Protocol (SNACP) to Proposed
Standard
Date: Mon, 12 Aug 1996 11:33:14 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9608121133.aa00014 at ietf.org>
The IESG has approved the Internet-Draft "The PPP SNA Control
Protocol (SNACP)" <draft-ietf-pppext-snacp-01.txt> as a Proposed
Standard. This document is the product of the Point-to-Point Protocol
Extensions Working Group. The IESG contact persons are Frank
Kastenholz and Jeffrey Burgan.
Technical Summary
Multiple higher-level protocols may operate over PPP links. For a
protocol to be carried over a PPP link, a control protocol is
required. This control protocol is used to negotiate the operations
of that protocol. The PPP SNA Control Protocol is used to configure
and control PPP links to carry SNA traffic.
Working Group Summary
This protocol was developed in the PPPEXT working group. Development
was without rancor.
Protocol Quality
The protocol has been reviewed by Frank Kastenholz.
Received: from ietf.org by ietf.org id aa08032; 12 Aug 96 15:51 EDT
Received: from aragorn.alternic.net by ietf.org id aa07829; 12 Aug 96 15:45 EDT
Received: (from ekashp at localhost) by aragorn.alternic.net (8.6.12/8.6.6) id MAA06004; Mon, 12 Aug 1996 12:45:35 -0700
Date: Mon, 12 Aug 1996 12:45:33 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Eugene Kashpureff <ekashp at alternic.net>
To: "Dale R. Worley" <worley at ariadne.com>
cc: ietf at ietf.org
Subject: Re: Internet Domain Survey, July 1996
In-Reply-To: <9608120940.aa24630 at ietf.org>
Message-ID: <Pine.LNX.3.91.960812122004.21118E at aragorn.alternic.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 12 Aug 1996, Dale R. Worley wrote:
> Well, at first glance, it would seem that your "unpopularity" has been
> exactly measured, at a count of 0 host names.
Na, one of our detractors from U Chicago measured it at 0.13% of
the name servers listed for the .COM zone as answerring for ALTERNIC.NIC.
.13% isn't spectacular, but it's not 0. And, hopefully we do a
good turn by raising awareness of Internationalization and TLD issues.
We've got a more comprhensive survey running now...
At your name service,
Eugene Kashpureff, ALTERNIC.NET
Received: from ietf.org by ietf.org id aa11101; 12 Aug 96 17:33 EDT
Received: from jekyll.piermont.com by ietf.org id aa11018; 12 Aug 96 17:30 EDT
Received: from localhost (perry at localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id RAA16269; Mon, 12 Aug 1996 17:18:40 -0400 (EDT)
Message-Id: <199608122118.RAA16269 at jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry at localhost didn't use HELO protocol
To: Eugene Kashpureff <ekashp at alternic.net>
cc: "Dale R. Worley" <worley at ariadne.com>, ietf at ietf.org
Subject: Re: Internet Domain Survey, July 1996
In-reply-to: Your message of "Mon, 12 Aug 1996 12:45:33 PDT."
<Pine.LNX.3.91.960812122004.21118E at aragorn.alternic.net>
Reply-To: perry at piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Mon, 12 Aug 1996 17:18:39 -0400
Sender:ietf-request at ietf.org
From: "Perry E. Metzger" <perry at piermont.com>
Source-Info: From (or Sender) name not authenticated.
Eugene Kashpureff writes:
> On Mon, 12 Aug 1996, Dale R. Worley wrote:
>
> > Well, at first glance, it would seem that your "unpopularity" has been
> > exactly measured, at a count of 0 host names.
>
> Na, one of our detractors from U Chicago measured it at 0.13% of
> the name servers listed for the .COM zone as answerring for ALTERNIC.NIC.
>
> .13% isn't spectacular, but it's not 0.
You neglect to mention that virtually every responding server was
either run by one of your unindicted co-conspirators or one of your
victims who has "bought" a TLD from you.
Perry
Received: from ietf.org by ietf.org id aa28627; 13 Aug 96 9:49 EDT
Received: from localhost by ietf.org id aa28325; 13 Aug 96 9:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: http-wg at cuckoo.hpl.hp.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-http-v11-spec-07.txt
Date: Tue, 13 Aug 1996 09:33:38 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608130933.aa28325 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Transfer Protocol
Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : Hypertext Transfer Protocol -- HTTP/1.1
Author(s) : R. Fielding, J. Gettys, J. Mogul,
H. Frystyk, T. Berners-Lee
Filename : draft-ietf-http-v11-spec-07.txt
Pages : 153
Date : 08/12/1996
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
distributed, collaborative, hypermedia information systems. It is a
generic, stateless, object-oriented protocol which can be used for many
tasks, such as name servers and distributed object management systems,
through extension of its request methods. A feature of HTTP is the typing
and negotiation of data representation, allowing systems to be built
independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information initiative
since 1990. This specification defines the protocol referred to as
"HTTP/1.1".
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-http-v11-spec-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-v11-spec-07.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-http-v11-spec-07.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960812134258.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-v11-spec-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-v11-spec-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960812134258.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29222; 13 Aug 96 10:19 EDT
Received: from cnri by ietf.org id aa29218; 13 Aug 96 10:19 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06785;
13 Aug 96 10:19 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <NAA10197 at pad-thai.cam.ov.com>; Tue, 13 Aug 1996 13:17:14 GMT
Received: from mail11.digital.com by MIT.EDU with SMTP
id AA05184; Tue, 13 Aug 96 09:17:13 EDT
Received: from us1rmc.bb.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV)
id JAA30701; Tue, 13 Aug 1996 09:04:24 -0400 (EDT)
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA20795; Tue, 13 Aug 96 09:05:27 -0400
Message-Id: <9608131305.AA20795 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Tue, 13 Aug 96 09:05:27 EDT
Date: Tue, 13 Aug 96 09:05:27 EDT
Sender:ietf-archive-request at ietf.org
From: "John Wray, Digital DPE, (508) 486-5210 13-Aug-1996 0754" <wray at tuxedo.enet.dec.com>
To: "cat-ietf at mit.edu"@in.enet.dec.com
Cc: wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu
Subject: GSSAPI V2 minor issues
In revising the V2 C-bindings I ran into one area in the high-level spec that
probably need some minor clarification.
I can't find a definition of confidentiality or integrity anywhere in the
high-level spec or the C-bindings document. In particular, there's no mention
of what assurance the GSSAPI provides of correct delivery (for confidentiality
protection), or data origin authentication & sequencing (for integrity
protection), when coupled with anonymity and/or non-mutual authentication.
As I read the specs, we have provided ways for each party to avoid
authenticating itself - the context acceptor doesn't authenticate itself if the
initiator doesn't request mutual authentication, and the initiator doesn't
authenticate itself if anonymity is requested.
I think the case of data origin authentication is straightforward - Succesfully
processing a integrity-protected message guarantees to the recipient that the
protection was applied to that message by the party at the other end of the
security context, whether or not that party's identity was authenticated at
context establishment.
However, it's not so straightforward in the case of confidentiality protection.
Consider the following description of a hypothetical mechanism:
Negotiate a session key, using a non-authenticated method (like
Diffie-Hellman). Tokens 1 & 2.
Initiator sends an authenticator under the negotiated session-key
to the acceptor. This authenticator would be signed by the
initiator's private key, and would have to contain some information
about the actual value of the "outer" session key, to protect against
active MITM attacks. Token 3. If mutual authentication was requested,
the acceptor replies with its own authenticator. Token 4.
Confidentiality and Integrity are implemented by using the session key.
While this mechanism can claim to support confidentiality, it's only after
mutual authentication is explicitly performed that it will actually give the
initiator what he expects from that service - Unless mutual authentication in
requested (and token 4 is succesfully received and processed), any messages to
which the initiator applies confidentiality protection could conceivably be
read by an attacker.
I'm not sure how to fix this. The straightforward answer seems to just
document this and say that confidentiality protection may not give you any
assurance that no-one other than the intended recipient can read your
messages unless you have authenticated the identity of the remote party.
However, if we do that, then initiator applications that care about
confidentiality will be forced to apply mutual authentication, even though,
under most mechanisms, this isn't necessary.
Alternatively, we could add some text that says that confidentiality protection
_does_ give an assurance that only the named parties (i.e. the principal named
by gss_init_sec_context's targ_name parameter and the principal named by
gss_accept_sec_context's src_name parameter) will be able to read the message.
This would mean that, for mechanisms like the one above, the initiator's GSSAPI
couldn't claim that confidentiality protection is available until the acceptor
has authenticated itself. However, this would mean that, for such a mechanism,
conf_avail will only return true once mutual authentication has been
succesfully performed (which also implies that a caller's request for
confidentiality would automatically enable mutual authentication). For more
normal mechanisms (where only the intended acceptor will be able to derive the
session key, whether or not mutual authentication is being explicitly
performed), confidentiality protection can be made available as soon as the
initial token has been generated.
For this to work properly, we should really require that the conf_avail and
integ_avail flags are valid whenever we set prot_ready_state (at both acceptor
and initiator). I think this in needed anyway, since an application that is
going to do anything based on the prot_ready_state flag will also want to know
what flavors of protection are ready.
If we do require these flags to be valid whenever prot_ready_state is true, how
about the state flags? Particularly replay_det_state and sequence_state? I
can envisage an application being unwilling to use per-message integrity unless
they are assured that these services are available.
Maybe we should simply require mechanisms to set the state flags (other than
anon_state) as soon as they are certain that the context will be able to
support the service. Since valid V1 apps won't look at the state flags until
the context establishment is complete, no changes we make here will affect
existing applications.
The only obvious exception is the anon_state flag, which should continue to be
a guarantee that neither the current emitted token (if there is one), nor any
previous tokens revealed the initiator's identity.
John
Received: from ietf.org by ietf.org id aa02511; 13 Aug 96 13:43 EDT
Received: from zephyr.isi.edu by ietf.org id aa02276; 13 Aug 96 13:33 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA22590>; Tue, 13 Aug 1996 10:33:56 -0700
Message-Id: <199608131733.AA22590 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1974 on Stac LZS
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 13 Aug 96 10:36:36 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1974:
Title: PPP Stac LZS Compression Protocol
Author: R. Friend & W. Simpson
Date: August 1996
Mailbox: rfriend at stac.com, bsimpson at MorningStar.com
Pages: 20
Characters: 45,267
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1974.txt
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links. The
PPP Compression Control Protocol provides a method to negotiate and
utilize compression protocols over PPP encapsulated links. This
document describes the use of the Stac LZS data compression algorithm,
with single or multiple compression histories, for compressing PPP
encapsulated packets. This RFC is the product of the Point-to-Point
Extensions Working Group of the IETF.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <960813103419.RFC at ISI.EDU>
SEND /rfc/rfc1974.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1974.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960813103419.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02756; 13 Aug 96 13:51 EDT
Received: from zephyr.isi.edu by ietf.org id aa02048; 13 Aug 96 13:31 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA22362>; Tue, 13 Aug 1996 10:31:15 -0700
Message-Id: <199608131731.AA22362 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1967 on LZS-DCP
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 13 Aug 96 10:33:55 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1967:
Title: PPP LZS-DCP Compression Protocol (LZS-DCP)
Author: K. Schneider & R. Friend
Date: August 1996
Mailbox: kschneider at adtran.com, rfriend at stac.com
Pages: 18
Characters: 40,039
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1967.txt
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links. The
PPP Compression Control Protocol provides a method to negotiate and
utilize compression protocols over PPP encapsulated links. This
document describes the use of the Stac LZS data compression algorithm
for compressing PPP encapsulated packets, using a DCP header. This
protocol is an enhanced version of the non-DCP (Option 17) PPP Stac
LZS compression protocol, and will be referred to as the LZS-DCP
Compression Protocol. This RFC is the product of the Point-to-Point
Protocol Extensions Working Group of the IETF.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <960813103102.RFC at ISI.EDU>
SEND /rfc/rfc1967.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1967.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960813103102.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03016; 13 Aug 96 14:02 EDT
Received: from localhost by ietf.org id aa02890; 13 Aug 96 13:59 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: SMTP Service Extension for Returning Enhanced
Error Codes to Proposed Standard
Date: Tue, 13 Aug 1996 13:59:13 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9608131359.aa02890 at ietf.org>
The IESG has approved the Internet-Draft "SMTP Service Extension for
Returning Enhanced Error Codes" <draft-freed-smtperror-01.txt> as a
Proposed Standard. The IESG contact persons are Keith Moore and
Harald Alvestrand.
Technical Summary
This extension to the SMTP protocol allows an SMTP server to indicate
to an SMTP client that certain of its reply messages contain enhanced
mail system status codes as defined in RFC 1893. This in turn allows
the SMTP client to include those codes in the per-recipient Status
field of RFC 1894 delivery status notifications (DSNs).
The RFC 1893 mail system status codes allow for more precise error
indications than the reply codes traditionally used by SMTP. These
status codes are already in use by MTAs that generate RFC 1894
delivery status notifications, for errors detected locally by those
MTAs. This extension allows such status codes to be included in DSNs
for errors reported by a remote server using SMTP.
Working Group Summary
This protocol was not reviewed by an active IETF working group.
However, the mailing list associated with the former NOTARY working
group was asked to review two proposals for reporting RFC 1893 status
codes. The responses were significantly in favor of this proposal.
In addition, the author of this proposal has revised it in response to
comments received from the NOTARY list.
Protocol Quality
Keith Moore reviewed the protocol for IESG.
Received: from ietf.org by ietf.org id aa15053; 14 Aug 96 2:18 EDT
Received: from cnri by ietf.org id aa14995; 14 Aug 96 2:12 EDT
Received: from gw.home.vix.com by CNRI.Reston.VA.US id aa02037;
14 Aug 96 2:12 EDT
Received: by gw.home.vix.com id XAA06544; Tue, 13 Aug 1996 23:12:42 -0700 (PDT)
Date: Tue, 13 Aug 1996 23:12:42 -0700 (PDT)
X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us
To: ietf at CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: Paul A Vixie <paul at vix.com>
Subject: Re: Internet Domain Survey, July 1996
Organization: Vixie Enterprises
Message-ID: <VIXIE.96Aug13231240 at wisdom.vix.com>
References: <9608120940.aa24630 at ietf.org>
<Pine.LNX.3.91.960812122004.21118E at aragorn.alternic.net>
NNTP-Posting-Host: wisdom.home.vix.com
In-reply-to: ekashp at alternic.net's message of 12 Aug 1996 15:32:58 -0700
Source-Info: From (or Sender) name not authenticated.
> Na, one of our detractors from U Chicago measured it at 0.13% of
> the name servers listed for the .COM zone as answerring for ALTERNIC.NIC.
There are 454,000 unique domains under COM served by 33,549 nameservers.
0.13% of 33,549 would be 43 nameservers, all of which would be customers
of AlterNIC who have not yet realized that they have been fleeced and who
have therefore not yet (so far as I have heard) sued Eugene.
> .13% isn't spectacular, but it's not 0.
The choir is preaching, what a surprise.
> And, hopefully we do a good turn by raising
> awareness of Internationalization and TLD issues.
The actual customers for new iTLDs have by and large never heard of you
and probably will never hear of you other than as a footnote in one of
the various history books that will in the future talk about the Bad Old
Days of COM.
> We've got a more comprhensive survey running now...
Me, too.
I have put the inverted COM zone data up for FTP on:
ftp://ftp.vix.com/pri/vixie/addresses.gz (servers and their addresses, 425K)
ftp://ftp.vix.com/pri/vixie/domains.gz (servers and their domains, 2708K)
The script I wrote to permute COM is ftp://ftp.vix.com/pri/vixie/parse-zonef,
but beware that it takes 200MB of VM to run, and really only wants InterNIC
style zone files, it won't parse the full input specification.
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul at vix.com>
pacbell!vixie!paul
Received: from ietf.org by ietf.org id aa18204; 14 Aug 96 6:17 EDT
Received: from cnri by ietf.org id aa18157; 14 Aug 96 6:14 EDT
Received: from igw.hkt.com by CNRI.Reston.VA.US id aa04289; 14 Aug 96 6:14 EDT
Received: by igw.hkt.com id <71442>; Wed, 14 Aug 1996 18:19:31 +0800
X-Sender: lodge at sndsn1.sedalia.sinet.slb.com
Message-Id: <96Aug14.181931hkt.71442 at igw.hkt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: Mathew Lodge <lodge at houston.omnes.net>
Subject: Advanced DHCP implementations wanted
Date:Wed, 14 Aug 1996 18:19:23 +0800
Source-Info: From (or Sender) name not authenticated.
I'm not sure if this is the right place to ask, but...
Has anyone implemented the extensions to DHCP discussed in the various
Internet drafts? By this, I mean the linking of DHCP leases to dynamic DNS
updates, and authentication for DNS requests.
Thanks,
Mathew
Received: from ietf.org by ietf.org id aa18816; 14 Aug 96 6:59 EDT
Received: from cnri by ietf.org id aa18771; 14 Aug 96 6:58 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa04631;
14 Aug 96 6:58 EDT
Received: from franklin.cris.com by venera.isi.edu (5.65c/5.61+local-25)
id <AA07779>; Wed, 14 Aug 1996 03:58:26 -0700
Received: from voyager.cris.com (voyager [199.3.12.37])
by franklin.cris.com (8.7.5/(96/06/11 2.45))
id GAA23445; Wed, 14 Aug 1996 06:58:20 -0400 (EDT)
[1-800-745-2747 The Concentric Network]
Sender:ietf-request at ietf.org
From: Dorisn at cris.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Errors-To: Dorisn at cris.com
Received: by voyager.cris.com (4.1) id AA26137; Wed, 14 Aug 96 06:56:57 EDT
Date: Wed, 14 Aug 96 06:56:57 EDT
Message-Id: <9608141056.AA26137 at voyager.cris.com>
To: ietf at isi.edu
Subject: Send FAX from your country to USA for US$0.075!!
Source-Info: From (or Sender) name not authenticated.
SEND FAX from your country to USA for US$0.075!!!
Dear friends:
We are very excited to tell you the CHEAPEST way to send fax to
anywhere in the world. You can send faxes right from your desktop, from
your email. You don't even need fax machine to send faxes.
Just take a look of the international fax rates below, and you will
know why we are so excited to share the news with you.
No matter where you are at, the rates are the same.
Sending faxes from your country to the following countries:
----------------------------------------------------
To Country Rates per minute
----------------------------------------------------
USA US$0.15
Canada US$0.28
United KingdomUS$0.33
Germany/FranceUS$0.43
Australia US$0.51
Japan US$0.51
Columbia US$0.60
Hong Kong US$0.54
Taiwan US$0.55
----------------------------------------------------
Remember that a typical one page will be sent in less than one
minute. For example, if your one page fax to the USA goes through
within 30 seconds, then you pay as low as US$0.075 for a one page
fax to the USA!
Better yet, you don't need a fax machine. You send the fax from your
Internet email account. It is called "email-to-fax", and the service
is offered by "ITSG, Inc."
How to sign up? Simple. Just fill out the on-line Order Form.
(http://www.itsg.com/cgi-bin/form?handler=ordform.frm)
Interested in being an Agent too? Check out their web site.
----------------------------------------------------------------
You can check out their web site -- http://www.itsg.com
(They also offer "fax-to-fax via Internet" service)
For free infomation -- send a blank email to "info at itsg.com"
----------------------------------------------------------------
If you like to order, just fill out the order form. Please fill in
"10015" in the "agent" field of the order form.
Thank you.
Regards,
Doris Newman
Received: from ietf.org by ietf.org id aa22277; 14 Aug 96 9:42 EDT
Received: from localhost by ietf.org id aa21108; 14 Aug 96 9:36 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-bernstein-qmtp-00.txt
Date: Wed, 14 Aug 1996 09:36:07 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608140936.aa21108 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Quick Mail Transfer Protocol (QMTP)
Author(s) : D. Bernstein
Filename : draft-bernstein-qmtp-00.txt
Pages : 5
Date : 08/13/1996
The Quick Mail Transfer Protocol (QMTP) is a replacement for the Simple
Mail Transfer Protocol (SMTP). QMTP eliminates any need for end-of-line
scanning between hosts with the same end-of-line convention. It features
automatic pipelining and chunking, 8-bit transmission, prior declaration
of the message size, and efficient batching. It is designed to be
very easy to implement.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-bernstein-qmtp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-bernstein-qmtp-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-bernstein-qmtp-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960813161940.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-bernstein-qmtp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-bernstein-qmtp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960813161940.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22942; 14 Aug 96 9:47 EDT
Received: from localhost by ietf.org id aa21139; 14 Aug 96 9:36 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-bernstein-owner-hack-00.txt
Date: Wed, 14 Aug 1996 09:36:20 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608140936.aa21139 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The Owner Hack
Author(s) : D. Bernstein
Filename : draft-bernstein-owner-hack-00.txt
Pages : 7
Date : 08/13/1996
The fundamental problem in managing a large mailing list is matching
bounce messages to subscription addresses.
Often a bounce message refers to a failing address that does not appear
on the mailing list. One of the mailing list subscribers is forwarding
messages to that address. Which subscriber? As the list grows,
this question becomes more and more difficult to answer.
The owner hack completely eliminates this problem _right now_.
It automatically and reliably identifies the subscription address
relevant to each bounce message. It provides the address in a form
that is trivial for automated bounce handlers to parse. It requires
support from the local mailer, but it does not require support
from any other hosts.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-bernstein-owner-hack-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-bernstein-owner-hack-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-bernstein-owner-hack-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960813163101.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-bernstein-owner-hack-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-bernstein-owner-hack-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960813163101.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22945; 14 Aug 96 9:47 EDT
Received: from localhost by ietf.org id aa20960; 14 Aug 96 9:35 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-gellens-telnet-char-option-04.txt, .ps
Date: Wed, 14 Aug 1996 09:35:25 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608140935.aa20960 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : TELNET CHARSET Option
Author(s) : R. Gellens
Filename : draft-gellens-telnet-char-option-04.txt, .ps
Pages : 17
Date : 08/13/1996
This document specifies a mechanism for passing character set and
translation information between a TELNET client and server. Use of this
mechanism enables an application used by a TELNET user to send and receive
data in the correct character set.
Either side can (subject to option negotiation) at any time
request that a (new) character set be used.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-gellens-telnet-char-option-04.txt".
Or
"get draft-gellens-telnet-char-option-04.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-gellens-telnet-char-option-04.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-gellens-telnet-char-option-04.txt".
Or
"FILE /internet-drafts/draft-gellens-telnet-char-option-04.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960813110215.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-gellens-telnet-char-option-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-gellens-telnet-char-option-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960813110215.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22962; 14 Aug 96 9:47 EDT
Received: from localhost by ietf.org id aa20995; 14 Aug 96 9:35 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: namedroppers at internic.net
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dnsind-2ndry-03.txt
Date: Wed, 14 Aug 1996 09:35:37 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608140935.aa20995 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the DNS IXFR, Notification, and
Dynamic Update Working Group of the IETF.
Title : Selection and Operation of Secondary DNS Servers
Author(s) : R. Elz, R. Bush, S. Bradner, M. Patton
Filename : draft-ietf-dnsind-2ndry-03.txt
Pages : 12
Date : 08/13/1996
The Domain Name System requires that multiple servers exist for every
delegated domain (zone). This document discusses the selection of
secondary servers for DNS zones. Both the physical and topological
location of each server are material considerations when selecting
secondary servers. The number of servers appropriate for a zone is also
discussed, and some general secondary server maintenance issues considered.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dnsind-2ndry-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-2ndry-03.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dnsind-2ndry-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960813111335.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnsind-2ndry-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnsind-2ndry-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960813111335.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22953; 14 Aug 96 9:47 EDT
Received: from localhost by ietf.org id aa21044; 14 Aug 96 9:35 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-bernstein-hcmssc-01.txt
Date: Wed, 14 Aug 1996 09:35:50 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608140935.aa21044 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The Hash Convention For Mail System Status Codes
(HCMSSC)
Author(s) : D. Bernstein
Filename : draft-bernstein-hcmssc-01.txt
Pages : 1
Date : 08/13/1996
RFC 1893 defines codes for mail delivery failures. For example, code 5.1.1
means that the specified mailbox does not exist.
The qmail package sprays these codes all over the place, by adding a code
to the text of every error message, preceded by a hash mark and surrounded
by parentheses. It avoids using hash marks elsewhere.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-bernstein-hcmssc-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-bernstein-hcmssc-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-bernstein-hcmssc-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960813154604.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-bernstein-hcmssc-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-bernstein-hcmssc-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960813154604.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22946; 14 Aug 96 9:47 EDT
Received: from localhost by ietf.org id aa20976; 14 Aug 96 9:35 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rsvp at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rsvp-spec-13.txt, .ps
Date: Wed, 14 Aug 1996 09:35:28 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608140935.aa20976 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Resource Reservation Setup
Protocol Working Group of the IETF.
Title : Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification
Author(s) : R. Braden, L. Zhang, S. Berson,
S. Herzog, S. Jamin
Filename : draft-ietf-rsvp-spec-13.txt, .ps
Pages : 119
Date : 08/13/1996
This memo describes version 1 of RSVP, a resource reservation setup
protocol designed for an integrated services Internet. RSVP provides
receiver-initiated setup of resource reservations for multicast or unicast
data flows, with good scaling and robustness properties.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rsvp-spec-13.txt".
Or
"get draft-ietf-rsvp-spec-13.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-spec-13.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rsvp-spec-13.txt".
Or
"FILE /internet-drafts/draft-ietf-rsvp-spec-13.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960813110808.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rsvp-spec-13.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-spec-13.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960813110808.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22949; 14 Aug 96 9:47 EDT
Received: from localhost by ietf.org id aa21076; 14 Aug 96 9:35 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-bernstein-nrudt-01.txt
Date: Wed, 14 Aug 1996 09:35:56 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608140935.aa21076 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Notice-Requested-Upon-Delivery-To (NRUDT)
Author(s) : D. Bernstein
Filename : draft-bernstein-nrudt-01.txt
Pages : 3
Date : 08/13/1996
The UNIX sendmail program has for many years supported a Return-Receipt-To
(RRT) header field that requests a notice of successful final delivery.
Notice-Requested-Upon-Delivery-To (NRUDT) has the same basic function. The
big difference is that RRT lists the sender's address, while NRUDT lists
the recipient's address.
This change is critical. RRT works poorly for messages to multiple
recipients, because it requests a notice from every recipient. RRT in a
message to a large mailing list produces a giant, usually unintentional,
flood of mail. This problem is so severe that RRT has been disabled in
recent versions of sendmail.
NRUDT is designed to be adopted immediately, with minimal disruption, as a
solution to the problems of RRT. Note that NRUDT is merely a request for
notification; unlike the link-level Delivery Status Notification SMTP
extension, NRUDT does not provide a guarantee of notification.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-bernstein-nrudt-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-bernstein-nrudt-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-bernstein-nrudt-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960813155641.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-bernstein-nrudt-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-bernstein-nrudt-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960813155641.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22960; 14 Aug 96 9:47 EDT
Received: from localhost by ietf.org id aa21011; 14 Aug 96 9:35 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-civanlar-bmpeg-00.txt
Date: Wed, 14 Aug 1996 09:35:40 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608140935.aa21011 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : RTP Payload Format for Bundled MPEG
Author(s) : R. Civanlar, G. Cash, B. Haskell
Filename : draft-civanlar-bmpeg-00.txt
Pages : 6
Date : 08/13/1996
This document describes a payload type for bundled, MPEG-2 encoded video
and audio data to be used with RTP, version 2. Bundling has several
advantages for this payload type particularly when it is used for
video-on-demand applications. A scheme for pre-transmission of vital
information to improve error resilience is described also.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-civanlar-bmpeg-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-civanlar-bmpeg-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-civanlar-bmpeg-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960813112908.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-civanlar-bmpeg-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-civanlar-bmpeg-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960813112908.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22961; 14 Aug 96 9:47 EDT
Received: from localhost by ietf.org id aa21092; 14 Aug 96 9:36 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-bernstein-pirp-01.txt
Date: Wed, 14 Aug 1996 09:36:01 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608140936.aa21092 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Public Information Retrieval Protocol (PIRP)
Author(s) : D. Bernstein
Filename : draft-bernstein-pirp-01.txt
Pages : 4
Date : 08/13/1996
The Public Information Retrieval Protocol (PIRP) gives Internet hosts a
simple, uniform, efficient, extensible, easily implemented method of
publishing information. This document defines PIRP and outlines the
structure of PIRP names.
Unlike FTP and HTTP, PIRP is dedicated to publication. Implementing PIRP
ought to be a small and trivial task.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-bernstein-pirp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-bernstein-pirp-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-bernstein-pirp-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960813161504.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-bernstein-pirp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-bernstein-pirp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960813161504.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22959; 14 Aug 96 9:47 EDT
Received: from localhost by ietf.org id aa21120; 14 Aug 96 9:36 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-bernstein-qsbmf-01.txt
Date: Wed, 14 Aug 1996 09:36:10 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608140936.aa21120 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The qmail-send Bounce Message Format (QSBMF)
Author(s) : D. Bernstein
Filename : draft-bernstein-qsbmf-01.txt
Pages : 4
Date : 08/13/1996
When a message transport agent (MTA) finds itself permanently unable to
deliver a mail message, it generates a new message, generally known as a
bounce message, back to the envelope sender.
Bounce messages produced by the qmail-send program display the list of
failed recipient addresses, an explanation for each address, and a copy of
the original message, in a format that is easy for both humans and programs
to read. This document defines the format.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-bernstein-qsbmf-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-bernstein-qsbmf-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-bernstein-qsbmf-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960813162410.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-bernstein-qsbmf-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-bernstein-qsbmf-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960813162410.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23116; 14 Aug 96 9:48 EDT
Received: from ietf.org by ietf.org id aa22958; 14 Aug 96 9:47 EDT
Received: from localhost by ietf.org id aa21060; 14 Aug 96 9:35 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-bernstein-netstrings-01.txt
Date: Wed, 14 Aug 1996 09:35:54 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608140935.aa21060 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Netstrings
Author(s) : D. Bernstein
Filename : draft-bernstein-netstrings-01.txt
Pages : 2
Date : 08/13/1996
A netstring is a self-delimiting encoding of a string. Netstrings are very
easy to generate and to parse. Any string may be encoded as a netstring;
there are no restrictions on length or on allowed bytes. Another virtue of
a netstring is that it declares the string size up front. Thus an
application can check in advance whether it has enough space to store the
entire string.
Netstrings may be used as a basic building block for reliable network
protocols. Most high-level protocols, in effect, transmit a sequence of
strings; those strings may be encoded as netstrings and then concatenated
into a sequence of characters, which in turn may be transmitted over a
reliable stream protocol such as TCP.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-bernstein-netstrings-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-bernstein-netstrings-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-bernstein-netstrings-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960813155053.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-bernstein-netstrings-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-bernstein-netstrings-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960813155053.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23117; 14 Aug 96 9:48 EDT
Received: from ietf.org by ietf.org id aa22963; 14 Aug 96 9:47 EDT
Received: from localhost by ietf.org id aa21028; 14 Aug 96 9:35 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-bernstein-eplf-01.txt
Date: Wed, 14 Aug 1996 09:35:48 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608140935.aa21028 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Easily Parsed LIST Format (EPLF)
Author(s) : D. Bernstein
Filename : draft-bernstein-eplf-01.txt
Pages : 5
Date : 08/13/1996
The File Transfer Protocol (FTP) supports two commands that list files:
NLST and LIST. The NLST response is easy to parse but provides very little
information. The LIST response provides more information, but in a format
that varies from system to system. The most common LIST formats are
undocumented and impossible to parse reliably.
This document defines Easily Parsed LIST Format (EPLF), a format for the
LIST response that is usable by humans yet easy for programs to handle.
This format is supported by anonftpd, a secure FTP server.
One visible advantage of EPLF is that a browser can easily display dates in
the viewer's time zone and native language. EPLF also makes it
straightforward for an indexing program to automatically traverse an FTP
area and for a mirroring program to avoid downloading the same file twice.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-bernstein-eplf-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-bernstein-eplf-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-bernstein-eplf-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960813152838.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-bernstein-eplf-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-bernstein-eplf-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960813152838.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23114; 14 Aug 96 9:48 EDT
Received: from ietf.org by ietf.org id aa22950; 14 Aug 96 9:47 EDT
Received: from localhost by ietf.org id aa20944; 14 Aug 96 9:35 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-hubbard-registry-guidelines-05.txt
Date: Wed, 14 Aug 1996 09:35:22 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608140935.aa20944 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Note: This revision reflects comments received during the last call period.
Title : INTERNET REGISTRY IP ALLOCATION GUIDELINES
Author(s) : K. Hubbard, M. Kosters, D. Conrad,
D. Karrenberg, J. Postel
Filename : draft-hubbard-registry-guidelines-05.txt
Pages : 13
Date : 08/13/1996
This document describes the registry system for the distribution of
globally unique Internet address space and registry operations.
Particularly this document describes the rules and guidelines governing
the distribution of this address space.
This document describes the IP assignment policies currently used by the
Regional Registries to implement the guidelines developed by the IANA. The
guidelines and these policies are subject to revision at the direction of
the IANA. The registry working group (IRE WG) will be discussing these
issues and may provide advice to the IANA about possible revisions.
This document replaces RFC 1466, with all the guidelines and procedures
updated and modified in the light of experience.
This document does not describe private Internet address space and
multicast address space. It also does not describe regional and
local refinements of the global rules and guidelines.
This document can be considered the base set of operational guidelines
in use by all registries. Additional guidelines may
be imposed by a particular registry as appropriate.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-hubbard-registry-guidelines-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hubbard-registry-guidelines-05.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-hubbard-registry-guidelines-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960813093115.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hubbard-registry-guidelines-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hubbard-registry-guidelines-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960813093115.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07967; 14 Aug 96 16:20 EDT
Received: from cnri by ietf.org id aa07963; 14 Aug 96 16:20 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16600;
14 Aug 96 16:20 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <TAA01326 at pad-thai.cam.ov.com>; Wed, 14 Aug 1996 19:33:51 GMT
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA02470; Wed, 14 Aug 96 15:33:50 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <TAA01319 at pad-thai.cam.ov.com>; Wed, 14 Aug 1996 19:33:41 GMT
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id PAA01135; Wed, 14 Aug 1996 15:33:39 -0400
Message-Id: <199608141933.PAA01135 at winkl.cam.ov.com>
To: "John Wray, Digital DPE,\
(508) 486-5210 13-Aug-1996 0754" <wray at tuxedo.enet.dec.com>
Cc: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: GSSAPI V2 minor issues
In-Reply-To: Your message of "Tue, 13 Aug 1996 09:05:27 EDT."
<9608131305.AA20795 at us1rmc.bb.dec.com>
Date: Wed, 14 Aug 1996 15:33:38 -0400
Sender:ietf-archive-request at ietf.org
From: John Linn <linn at cam.ov.com>
John Wray notes, excerpting:
>I'm not sure how to fix this. The straightforward answer seems to just
>document this and say that confidentiality protection may not give you any
>assurance that no-one other than the intended recipient can read your
>messages unless you have authenticated the identity of the remote party.
>However, if we do that, then initiator applications that care about
>confidentiality will be forced to apply mutual authentication, even though,
>under most mechanisms, this isn't necessary.
>
>Alternatively, we could add some text that says that confidentiality protection
>_does_ give an assurance that only the named parties (i.e. the principal named
>by gss_init_sec_context's targ_name parameter and the principal named by
>gss_accept_sec_context's src_name parameter) will be able to read the message.
I'd prefer the second choice, if it doesn't collide with any existing
mechanisms; the ability to provide per-message confidentiality (where
"confidential" means "confidential to the named target as requested for
a context") without incurring added context setup hops for mutual
authentication seems like a useful fit for some applications. I
believe that both Kerberos and SPKM satisfy this property; does anyone
know of concrete GSS-API mechanisms which would be impacted if such
a requirement were to be imposed?
>This would mean that, for mechanisms like the one above, the initiator's GSSAPI
>couldn't claim that confidentiality protection is available until the acceptor
>has authenticated itself. However, this would mean that, for such a mechanism,
>conf_avail will only return true once mutual authentication has been
>succesfully performed (which also implies that a caller's request for
>confidentiality would automatically enable mutual authentication). For more
>normal mechanisms (where only the intended acceptor will be able to derive the
>session key, whether or not mutual authentication is being explicitly
>performed), confidentiality protection can be made available as soon as the
>initial token has been generated.
Not necessarily the initial token; a mechanism could derive session
keys in a manner which involves inputs (and, hence, tokens) from both
peers.
>For this to work properly, we should really require that the conf_avail and
>integ_avail flags are valid whenever we set prot_ready_state (at both acceptor
>and initiator). I think this in needed anyway, since an application that is
>going to do anything based on the prot_ready_state flag will also want to know
>what flavors of protection are ready.
I agree; if they're returnable upon GSS_S_COMPLETE, they should also
be returnable upon GSS_S_CONTINUE_NEEDED && (prot_ready_state == TRUE).
>If we do require these flags to be valid whenever prot_ready_state is true, how
>about the state flags? Particularly replay_det_state and sequence_state? I
>can envisage an application being unwilling to use per-message integrity unless
>they are assured that these services are available.
Seems reasonable for replay_det_state and sequence_state as well.
>Maybe we should simply require mechanisms to set the state flags (other than
>anon_state) as soon as they are certain that the context will be able to
>support the service. Since valid V1 apps won't look at the state flags until
>the context establishment is complete, no changes we make here will affect
>existing applications.
Requiring mechanisms to switch the bits on incrementally as they become
determinable seems like a pervasive change which could impact the
structure of existing mechanism implementations without adding major
value. I wouldn't suggest going before the point in context establishment
where TRUE prot_ready_state is returned (which, of course, arises only
for those mechanisms which indicate this optional facility). Note,
for this case, that some values (e.g., mutual_state) which aren't set
at prot_ready_state time could be set later, at GSS_S_COMPLETE time.
--jl
Received: from ietf.org by ietf.org id aa08453; 14 Aug 96 16:34 EDT
Received: from zephyr.isi.edu by ietf.org id aa08084; 14 Aug 96 16:28 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA27662>; Wed, 14 Aug 1996 13:28:28 -0700
Message-Id: <199608142028.AA27662 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1981 on Path MTU Discovery for IPv6
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 14 Aug 96 13:31:08 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1981:
Title: Path MTU Discovery for IP version 6
Author: J. McCann, S. Deering & J. Mogul
Date: August 1996
Mailbox: mccann at zk3.dec.com, deering at parc.xerox.com,
mogul at pa.dec.com
Pages: 15
Characters: 34,088
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1981.txt
This document describes Path MTU Discovery for IP version 6. It is
largely derived from RFC 1191, which describes Path MTU Discovery for
IP version 4. This RFC is the product of the IPNG Working Group of
the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <960814132816.RFC at ISI.EDU>
SEND /rfc/rfc1981.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1981.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960814132816.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08457; 14 Aug 96 16:34 EDT
Received: from zephyr.isi.edu by ietf.org id aa08294; 14 Aug 96 16:31 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA27771>; Wed, 14 Aug 1996 13:31:50 -0700
Message-Id: <199608142031.AA27771 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1976 on PPP DCE
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 14 Aug 96 13:34:30 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1976:
Title: PPP for Data Compression in Data
Circuit-Terminating Equipment (DCE)
Author: K. Schneider & S. Venters
Date: August 1996
Mailbox: kschneider at adtran.com, sventers at adtran.com
Pages: 10
Characters: 19,781
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1976.txt
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP
defines an extensible Link Control Protocol, and proposes a family of
Network Control Protocols for establishing and configuring different
network-layer protocols. The PPP Serial Data Transport Protocol
(PPP-SDTP) provides a standard method for encapsulating and
transporting serial data over a PPP link. The PPP Compression Control
Protocol provides a standard method for selecting and using a
compression protocol to provide for data compression on a PPP link.
This document defines a specific set of parameters for these protocols
and an LCP extension to define a standard way of using PPP for data
compression of serial data in Data Circuit-Terminating Equipment
(DCE). This RFC is the product of the Point-to-Point Protocol
Extensions Working Group of the IETF.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <960814133220.RFC at ISI.EDU>
SEND /rfc/rfc1976.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1976.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960814133220.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08459; 14 Aug 96 16:34 EDT
Received: from zephyr.isi.edu by ietf.org id aa08031; 14 Aug 96 16:25 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA27476>; Wed, 14 Aug 1996 13:25:02 -0700
Message-Id: <199608142025.AA27476 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1985 on SMTP Service Extension - ETRN
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 14 Aug 96 13:27:42 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1985:
Title: SMTP Service Extension
for Remote Message Queue Starting
Author: J. De Winter
Date: August 1996
Mailbox: jack at wildbear.on.ca
Pages: 7
Characters: 14,815
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1985.txt
This memo defines an extension to the SMTP service whereby an SMTP
client and server may interact to give the server an opportunity to
start the processing of its queues for messages to go to a given host.
This extension is meant to be used in startup conditions as well as
for mail nodes that have transient connections to their service
providers.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <960814131044.RFC at ISI.EDU>
SEND /rfc/rfc1985.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1985.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960814131044.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08615; 14 Aug 96 16:37 EDT
Received: from zephyr.isi.edu by ietf.org id aa08534; 14 Aug 96 16:35 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA28015>; Wed, 14 Aug 1996 13:35:53 -0700
Message-Id: <199608142035.AA28015 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1963 on PPP SDTP
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 14 Aug 96 13:38:33 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1963:
Title: PPP Serial Data Transport Protocol (SDTP)
Author: K. Schneider & S. Venters
Date: August 1996
Mailbox: kschneider at adtran.com, sventers at adtran.com
Pages: 20
Characters: 38,185
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1963.txt
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP
defines an extensible Link Control Protocol, and proposes a family of
Network Control Protocols for establishing and configuring different
network-layer protocols. This document describes a new Network level
protocol (from the PPP point of view), PPP Serial Data Transport
Protocol, that provides encapsulation and an associated control
protocol for transporting serial data streams over a PPP link. This
protocol was developed for the purpose of using PPP's many features to
provide a standard method for synchronous data compression. The
encapsulation uses a header structure based on that of the ITU-T
Recommendation V.120. This RFC is the product of the Point-to-Point
Protocol Extensions Working Group of the IETF.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <960814133517.RFC at ISI.EDU>
SEND /rfc/rfc1963.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1963.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960814133517.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08815; 14 Aug 96 16:40 EDT
Received: from zephyr.isi.edu by ietf.org id aa08728; 14 Aug 96 16:38 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA28238>; Wed, 14 Aug 1996 13:38:59 -0700
Message-Id: <199608142038.AA28238 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1980 on Client-Side Image Maps
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 14 Aug 96 13:41:39 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1980:
Title: A Proposed Extension to HTML : Client-Side Image
Maps
Author: J. Seidman
Date: August 1996
Mailbox: jim at spyglass.com
Pages: 7
Characters: 13,448
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1980.txt
The markup language known as "HTML/2.0" provides for image maps.
Image maps are document elements which allow clicking different areas
of an image to reference different network resources, as specified by
Uniform Identifier (URIs). The image map capability in HTML/2.0 is
limited in several ways, such as the restriction that it only works
with documents served via the "HTTP" protocol, and the lack of a
viable fallback for users of text-only browsers. This document
specifies an extension to the HTML language, referred to as
"Client-Side Image Maps," which resolves these limitations.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <960814133845.RFC at ISI.EDU>
SEND /rfc/rfc1980.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1980.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960814133845.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12000; 14 Aug 96 17:48 EDT
Received: from cnri by ietf.org id aa11996; 14 Aug 96 17:48 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18660;
14 Aug 96 17:48 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <VAA05133 at pad-thai.cam.ov.com>; Wed, 14 Aug 1996 21:22:30 GMT
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA14238; Wed, 14 Aug 96 17:21:14 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA24427; Wed, 14 Aug 1996 17:21:13 -0400
Date: Wed, 14 Aug 1996 17:21:13 -0400
Message-Id: <9608142121.AA24427 at dcl.MIT.EDU>
Sender:ietf-archive-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: John Linn <linn at cam.ov.com>
Cc: "John Wray, Digital DPE, 486-5210 13-Aug-1996 0754" <wray at tuxedo.enet.dec.com>,
cat-ietf at mit.edu, linn at cam.ov.com
In-Reply-To: John Linn's message of Wed, 14 Aug 1996 15:33:38 -0400,
<199608141933.PAA01135 at winkl.cam.ov.com>
Subject: Re: GSSAPI V2 minor issues
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Wed, 14 Aug 1996 15:33:38 -0400
From: John Linn <linn at cam.ov.com>
>Maybe we should simply require mechanisms to set the state flags (other than
>anon_state) as soon as they are certain that the context will be able to
>support the service. Since valid V1 apps won't look at the state flags until
>the context establishment is complete, no changes we make here will affect
>existing applications.
Requiring mechanisms to switch the bits on incrementally as they become
determinable seems like a pervasive change which could impact the
structure of existing mechanism implementations without adding major
value. I wouldn't suggest going before the point in context establishment
where TRUE prot_ready_state is returned (which, of course, arises only
for those mechanisms which indicate this optional facility).
Agreed. It's also not at all clear how useful it would be to switch on
the bits before prot_ready_state is TRUE anyway. You can't do anything
with a context before prot_ready_state is TRUE (for those mechanism that
support it) or before GSS_S_COMPLETE (for those mechanisms that don't
support prot_ready_state).
- Ted
Received: from ietf.org by ietf.org id aa29079; 15 Aug 96 7:06 EDT
Received: from spinoza.terena.nl by ietf.org id aa28988; 15 Aug 96 6:59 EDT
Received: from [192.87.30.51] (PaulsMac.terena.nl [192.87.30.51]) by spinoza.terena.nl (8.6.13/8.6.12) with SMTP id MAA17229; Thu, 15 Aug 1996 12:59:28 +0200
X-Sender: paul at popper.terena.nl
Message-Id: <v02130506ae38b04d60f3 at [192.87.30.51]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 15 Aug 1996 13:02:17 +0200
To: terena-ga at terena.nl, wg-all at terena.nl, newsletters at terena.nl,
ceec at terena.nl, ietf at ietf.org, ccirn at lbl.gov, apng-all at apng.org,
jenc8-info at terena.nl, jenc8-pc at terena.nl, press at terena.nl,
lhl at cs.wisc.edu
Sender:ietf-request at ietf.org
From: Paul Rendek <paul at terena.nl>
Subject: JENC8 "CALL FOR PAPERS" - May 12-15 1997, Edinburgh, Scotland
Source-Info: From (or Sender) name not authenticated.
"8th Joint European Networking Conference" (JENC8)
Edinburgh, Scotland, 12-15 May 1997
"Diversity and Integration: The New European Networking Landscape"
The JENC8 "CALL FOR PAPERS" and general conference information
is now available via the Web. Please visit the JENC8 conference
Web site for further information at:
http://www.terena.nl/jenc8
For general enquiries please send a message to <jenc8-sec at TERENA.nl>
or contact
TERENA Secretariat
Singel 466-468
NL - 1017 AW Amsterdam
The Netherlands
Tel: +31 20 639 1131
Fax: +31 20 639 3289
Email: jenc8-sec at TERENA.nl
Received: from ietf.org by ietf.org id aa03107; 15 Aug 96 9:21 EDT
Received: from localhost by ietf.org id aa01611; 15 Aug 96 9:16 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mhtml at segate.sunet.se
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mhtml-cid-00.txt
Date: Thu, 15 Aug 1996 09:16:04 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608150916.aa01611 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MIME Encapsulation of
Aggregate HTML Documents Working Group of the IETF.
Title : Content-ID and Message-ID Uniform Resource Locators
Author(s) : E. Levinson
Filename : draft-ietf-mhtml-cid-00.txt
Pages : 4
Date : 08/14/1996
The Uniform Resource Locator (URL) schemes, "cid:"; and "mid:"; allow the
content of Text/HTML or other MIME media types to contain references to
other body parts in the same or a different message.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mhtml-cid-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mhtml-cid-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mhtml-cid-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960814105812.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mhtml-cid-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mhtml-cid-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960814105812.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03093; 15 Aug 96 9:21 EDT
Received: from localhost by ietf.org id aa01692; 15 Aug 96 9:16 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: int-serv at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-intserv-rsvp-use-00.txt
Date: Thu, 15 Aug 1996 09:16:17 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608150916.aa01692 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integrated Services Working
Group of the IETF.
Title : The Use of RSVP with IETF Integrated Services
Author(s) : J. Wroclawski
Filename : draft-ietf-intserv-rsvp-use-00.txt
Pages : 24
Date : 08/14/1996
This note describes the use of the RSVP resource reservation protocol with
the Controlled-Load and Guaranteed QoS control services. The RSVP protocol
defines several data objects which carry resource reservation information
but are opaque to RSVP itself. The usage and data format of those objects
is given here.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-intserv-rsvp-use-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-intserv-rsvp-use-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-intserv-rsvp-use-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960814155103.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-intserv-rsvp-use-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-intserv-rsvp-use-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960814155103.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03097; 15 Aug 96 9:21 EDT
Received: from localhost by ietf.org id aa01570; 15 Aug 96 9:15 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: int-serv at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-intserv-guaranteed-svc-06.txt
Date: Thu, 15 Aug 1996 09:15:34 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608150915.aa01570 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integrated Services Working
Group of the IETF.
Title : Specification of Guaranteed Quality of Service
Author(s) : S. Shenker, C. Partridge, R. Guerin
Filename : draft-ietf-intserv-guaranteed-svc-06.txt
Pages : 19
Date : 08/14/1996
This memo describes the network element behavior required to deliver a
guaranteed service (guaranteed delay and bandwidth) in the Internet.
Guaranteed service provides firm (mathematically provable) bounds on
end-to-end datagram queueing delays. This service makes it possible to
provide a service that guarantees both delay and bandwidth. This
specification follows the service specification template described in [1].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-intserv-guaranteed-svc-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-intserv-guaranteed-svc-06.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-intserv-guaranteed-svc-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960814104337.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-intserv-guaranteed-svc-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-intserv-guaranteed-svc-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960814104337.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03088; 15 Aug 96 9:21 EDT
Received: from localhost by ietf.org id aa01551; 15 Aug 96 9:15 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-bradner-key-words-00.txt
Date: Thu, 15 Aug 1996 09:15:28 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608150915.aa01551 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Key words for use in RFCs to
Indicate Requirement Levels
Author(s) : S. Bradner
Filename : draft-bradner-key-words-00.txt
Pages : 2
Date : 08/14/1996
In many standards track documents several words are used to signify the
requirements of the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF
documents. Note that the force of these words is modified by the
requirement level of the document itself.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-bradner-key-words-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-bradner-key-words-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-bradner-key-words-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960814103715.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-bradner-key-words-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-bradner-key-words-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960814103715.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03103; 15 Aug 96 9:21 EDT
Received: from localhost by ietf.org id aa01627; 15 Aug 96 9:16 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-kemp-auth-pklogin-01.txt, .ps
Date: Thu, 15 Aug 1996 09:16:06 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608150916.aa01627 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The Public Key Login Protocol
Author(s) : D. Kemp
Filename : draft-kemp-auth-pklogin-01.txt, .ps
Pages : 18
Date : 08/14/1996
This document specifies the Public Key Login protocol, an ISO 9798-3 based
security protocol which uses digital signatures to provide strong
authentication for interactive sessions. It is suitable for use with
unmodified session protocols such as Telnet and FTP, firewall proxies,
dial-up Network Access Servers, remote mail servers, and similar
applications. It provides functionality similar to One Time Passwords or
handheld authentication tokens, and supports both one-way and mutual
authentication. The protocol does not require the use of public key
certificates and the associated infrastructure but can make use of them if
they are available.
The Public Key Login protocol provides strong authentication at the
beginning of a session and perhaps periodically thereafter, but
does not provide communication channel integrity or confidentiality.
Channel integrity is required in order to fully realize
the benefits of strong authentication.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-kemp-auth-pklogin-01.txt".
Or
"get draft-kemp-auth-pklogin-01.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-kemp-auth-pklogin-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-kemp-auth-pklogin-01.txt".
Or
"FILE /internet-drafts/draft-kemp-auth-pklogin-01.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960814133852.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-kemp-auth-pklogin-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-kemp-auth-pklogin-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960814133852.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03456; 15 Aug 96 9:21 EDT
Received: from ietf.org by ietf.org id aa03104; 15 Aug 96 9:21 EDT
Received: from localhost by ietf.org id aa01666; 15 Aug 96 9:16 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipsec at tis.com
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-skip-07.txt
Date: Thu, 15 Aug 1996 09:16:15 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608150916.aa01666 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : Simple Key-Management For Internet Protocols (SKIP)
Author(s) : A. Aziz, T. Markson, H. Prafullchandra
Filename : draft-ietf-ipsec-skip-07.txt
Pages : 34
Date : 08/14/1996
There are occasions where it is advantageous to put authenticity and
privacy features at the network layer. The vast majority of the privacy and
authentication protocols in the literature deal with session oriented
key-management schemes. However, many of the commonly used network layer
protocols (for example, IPv4 and IPv6) are session-less datagram oriented
protocols. We describe a key-management scheme that is particularly well
suited for use in conjunction with a session-less datagram protocol like
IPv4 or IPv6.
SKIP has been designed to work with the IP Security Protocols AH and ESP
[8, 9, 10] which are specified for both IPv4 and IPv6.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-skip-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-07.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-skip-07.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960814144020.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-skip-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-skip-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960814144020.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03445; 15 Aug 96 9:21 EDT
Received: from ietf.org by ietf.org id aa03105; 15 Aug 96 9:21 EDT
Received: from localhost by ietf.org id aa01595; 15 Aug 96 9:16 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipng at sunroof.eng.sun.com
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-cisco-ipv6-router-alert-01.txt
Date: Thu, 15 Aug 1996 09:16:01 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608150916.aa01595 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IPv6 Router Alert Option
Author(s) : D. Katz, R. Atkinson
Filename : draft-cisco-ipv6-router-alert-01.txt
Pages : 4
Date : 08/14/1996
This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit
routers to more closely examine the contents of an IP packet. This is
useful for protocols addressed to a destination but also require special
processing in routers along the path.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-cisco-ipv6-router-alert-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-cisco-ipv6-router-alert-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-cisco-ipv6-router-alert-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960814105025.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-cisco-ipv6-router-alert-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-cisco-ipv6-router-alert-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960814105025.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03448; 15 Aug 96 9:21 EDT
Received: from ietf.org by ietf.org id aa03106; 15 Aug 96 9:21 EDT
Received: from localhost by ietf.org id aa01643; 15 Aug 96 9:16 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: int-serv at isi.edu
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-intserv-ctrl-load-svc-03.txt
Date: Thu, 15 Aug 1996 09:16:13 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608150916.aa01643 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integrated Services Working
Group of the IETF.
Title : Specification of the Controlled-Load
Network Element Service
Author(s) : J. Wroclawski
Filename : draft-ietf-intserv-ctrl-load-svc-03.txt
Pages : 18
Date : 08/14/1996
This memo specifies the network element behavior required to deliver
Controlled-Load service in the Internet. Controlled-load service provides
the client data flow with a quality of service closely approximating the
QoS that same flow would receive from an unloaded network element, but uses
capacity (admission) control to assure that this service is received even
when the network element is overloaded.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-intserv-ctrl-load-svc-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-intserv-ctrl-load-svc-03.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-intserv-ctrl-load-svc-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960814132034.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-intserv-ctrl-load-svc-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-intserv-ctrl-load-svc-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960814132034.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03457; 15 Aug 96 9:21 EDT
Received: from ietf.org by ietf.org id aa03109; 15 Aug 96 9:21 EDT
Received: from localhost by ietf.org id aa01717; 15 Aug 96 9:16 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: http-wg at cuckoo.hpl.hp.com
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-holtman-http-negotiation-02.txt
Date: Thu, 15 Aug 1996 09:16:19 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608150916.aa01717 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Transfer Protocol
Working Group of the IETF.
Title : Transparent Content Negotiation in HTTP
Author(s) : K. Holtman
Filename : draft-holtman-http-negotiation-02.txt
Pages : 38
Date : 08/14/1996
HTTP allows one to put multiple versions of the same information under a
single URL. Transparent content negotiation is a mechanism, layered on top
of HTTP, for automatically selecting the best version when the URL is
accessed. This enables the smooth deployment of new web data formats
and markup tags.
Design goals for transparent content negotiation include low overhead on
the request message size, downwards compatibility, extensibility, enabling
the rapid introduction of new areas of negotiation, scalability, low cost
of minimal support, end user control, and good cachability.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-holtman-http-negotiation-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-holtman-http-negotiation-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-holtman-http-negotiation-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at ietf.org
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960814163740.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-holtman-http-negotiation-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-holtman-http-negotiation-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960814163740.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa10037; 15 Aug 96 11:33 EDT
Received: from cnri by ietf.org id aa10033; 15 Aug 96 11:33 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa08836;
15 Aug 96 11:33 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <PAA00456 at pad-thai.cam.ov.com>; Thu, 15 Aug 1996 15:02:35 GMT
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA17575; Thu, 15 Aug 96 11:02:23 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <PAA00449 at pad-thai.cam.ov.com>; Thu, 15 Aug 1996 15:02:21 GMT
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id LAA01364; Thu, 15 Aug 1996 11:02:20 -0400
Message-Id: <199608151502.LAA01364 at winkl.cam.ov.com>
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Cc: John Linn <linn at cam.ov.com>,
"John Wray, Digital DPE,\
486-5210 13-Aug-1996 0754" <wray at tuxedo.enet.dec.com>,
cat-ietf at mit.edu, linn at cam.ov.com
Subject: New GSS-V2 I-D, "WG Final-Call" [Was: Re: GSSAPI V2 minor issues]
In-Reply-To: Your message of "Wed, 14 Aug 1996 17:21:13 EDT."
<9608142121.AA24427 at dcl.MIT.EDU>
Date: Thu, 15 Aug 1996 11:02:19 -0400
Sender:ietf-archive-request at ietf.org
From: John Linn <linn at cam.ov.com>
All:
In response to this discussion, I've taken the step of editing the
following changes into a new Internet-Draft, which I've submitted
(along with the new compatibility appendix and security considerations
section, as posted to the list on 5 August and against which no
comments have been received), to become draft-ietf-cat-gssv2-07.txt.
In the hope that this result will represent WG consensus for closure
on the issue, I'll hereby open a "WG Final-Call" on gssv2-07, to
extend through Wednesday, 28 August. Unless objections or
requirements for additional content fixes arise during this window,
the document will be resubmitted to the IESG thereafter.
--jl
------
Specific changes re "services and flags":
In Sec. 1.2.2, Per-Message Security Service Availability, added:
The GSS-API per-message integrity and data origin authentication
services provide assurance to a receiving caller that protection was
applied to a message by the caller's peer on the security context,
corresponding to the entity named at context initiation. The GSS-API
per-message confidentiality service provides assurance to a sending
caller that the message's content is protected from access by entities
other than the context's named peer.
In Sec. 1.2.7, Per-Message Protection During Context Establishment, added:
When prot_ready_state is returned TRUE, mechanisms shall also set
those context service indicator flags (deleg_state, mutual_state,
replay_det_state, sequence_state, anon_state, trans_state, conf_avail,
integ_avail) which represent facilities confirmed, at that time, to be
available on the context being established. In situations where
prot_ready_state is returned before GSS_S_COMPLETE, it is possible
that additional facilities may be confirmed and subsequently indicated
when GSS_S_COMPLETE is returned.
Made corresponding changes in Secs. 2.2.1 (GSS_Init_sec_context()) and
2.2.2 (GSS_Accept_sec_context()).
Received: from ietf.org by ietf.org id aa10514; 15 Aug 96 11:50 EDT
Received: from rodan.rs.itd.umich.edu by ietf.org id aa10397;
15 Aug 96 11:46 EDT
Received: from wander.merit.edu by rodan.rs.itd.umich.edu (8.7.5/2)
id LAA04753; Thu, 15 Aug 1996 11:46:05 -0400 (EDT)
Message-Id: <199608151546.LAA04753 at rodan.rs.itd.umich.edu>
Date: Thu, 15 Aug 1996 11:46:05 -0400 (EDT)
X-Sender: wbn at w.imap.itd.umich.edu
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: "William B. Norton" <wbn at umich.edu>
Subject: Call for Volunteers in Internet Routing Stability Study
Source-Info: From (or Sender) name not authenticated.
C a l l f o r V o l u n t e e r s !
Hi -
Merit Network is seeking volunteers to participate in an Internet routing
stability measurement initiative. This project provides one of the few
global Internet performance measurements, allowing the participants (and the
Internet community) to gain empirical insights regarding Internet routing
stability trends. We hope to be able to answer questions including:
During the past year of explosive Internet growth, is the end-user seeing
Internet stability improving, getting worse, or remaining about the same?
What types of routing anomalies are present in the Internet?
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.
