[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
- Bounced through innocent third party machines
- Is reflected through third party mailing lists (such as this one).
To my mind, this is really no different than someone phone phreking into
a company's telephone system and using it to make long distance calls,
i.e. it's criminal theft of computer time, network bandwidth, and of
the mailing list.
Given that the spammers are organized, profit making enterprises which
make a business of engaging in this criminal conduct across state lines,
it seems that one could consider them as subject not only to traditional
criminal laws but also to RICO and similar organized crime statutes. These
are big *existing* hammers that could send Spamford and his ilk to
prison.(*)
--karl--
(*) I'm sure an arrested spammer would appreciate that there is a service
offered to ambulance chasing lawyers -- the service scans arrest records
and generates an "if you need a lawyer" solicitation letter.
Received: from ietf.org by ietf.org id aa19878; 23 May 97 17:41 EDT
Received: from zephyr.isi.edu by ietf.org id aa19830; 23 May 97 17:40 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
id <AA01077>; Fri, 23 May 1997 14:37:06 -0700
Message-Id: <199705232137.AA01077 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2149 on Multicast Server Architectures
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 23 May 97 14:37:06 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 2149:
Title: Multicast Server Architectures for MARS-based
ATM multicasting
Author: R. Talpade, M. Ammar
Date: May 1997
Mailbox: taddy at cc.gatech.edu, ammar at cc.gatech.edu
Pages: 18
Characters: 42007
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2149.txt
Two basic approaches exist for the intra-subnet (intra-cluster)
multicasting of IP packets. One makes use of a mesh of point to
multipoint VCs (the 'VC Mesh' approach), while the other uses a shared
point to multipoint tree rooted on a Multicast Server (MCS). This
memo provides details on the design and implementation of an MCS,
building on the core mechanisms defined in RFC 2022. It also provides
a mechanism for using multiple MCSs per group for providing fault
tolerance. This document is the product of the Internetworking Over
NBMA 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 and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970523143228.RFC at ISI.EDU>
SEND /rfc/rfc2149.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2149.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970523143228.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa20995; 23 May 97 19:07 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13624;
23 May 97 19:07 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <UAA09611 at pad-thai.cam.ov.com>; Fri, 23 May 1997 20:54:24 GMT
Message-Id: <199705232054.AA02890 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: Snego & GSS V2
To: Mike Swift <mikesw at microsoft.com>
Date: Fri, 23 May 1997 16:29:19 -0400 (EDT)
Cc: cat-ietf at mit.edu
In-Reply-To: <F0C5060A8699D011A2B100805F14C869C75D89 at RED-75-MSG.dns.microsoft.com> from "Mike Swift" at May 23, 97 11:47:47 am
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Mike Swift wrote:
>
> I think that by specifying the logic used by the server will limit the
> usefulness of this draft - if the defined behavior doesn't match what is
> needed by a particular software vendor, they will have no choice but to
> go outside of SPNEGO. However, by just recommending a policy for the
> target and not mandating it we can increase the usage of SPNEGO. I don't
> think that being able to verify that two implementations behave the same
> is enough of a justification to limit the protocol - while it is useful,
> the fact that the client & server can authenticate should be the
> overriding concern. One way to think about this is that the target's
> ordering of mechanisms is dynamic - no where does it mention that the
> list must be fixed for all clients. The target can re-order its list of
> mechanisms (in whatever way it feels is reasonable and secure) based on
> the initial token sent by the client.
>
> As to the issue of negotiating confidentiality & integrity, I think
> these are among the two most important things that can be negotiated. I
> can see why they may not be necessary for a normal GSS implementation -
> either the protocol supports them or it doesn't, and the caller is free
> to use the services if they are available. However, in the presence of
> negotiation it is critical that it be possible to request such services.
> I think it is worth adding a conf_req_flag and anon_req_flag to the
> GSS_init_sec_context call. It requires no additional work for existing
> providers because they already return the flags if confidentiality or
> integrity is available, and for a negotiating package they are useful in
> determing what mechanism to use.
To make this work, these bits would have to be sent along with the
negotiation tokens. One big problem with GSS-API is, that information
about availability of integrity and confidentiality services can not
necessesarily be determined before successful security context
establishment.
I assume that was done so that a basic mechanism could define different
sets of algorithms (QOPs), and it could happen that two different
implementations did support the same authentication and integrity
algorithm sets, but different (optional!) confidentiality algorithm sets
(probably due to export control and intelectual property rights issues ...).
Not even potential availability can be queried through regular API
calls (I'm badly missing this functionality myself -- it wouldn't
be accurate all the time, but most of the time).
Hmmmm... I don't see an easy way to solve this problem.
One could add a req_flags input parameter to GSS_Set_neg_mechs() and
a req_flags output parameter to GSS_Get_neq_mechs() to specify
features that should be used for chosing an acceptable mechanism with
priority to the preference list (or the order of the preference list).
It should only be a "request", so the context establishment should
be completed with the closest fit, even if it doesn't meet the requested
features.
Still, figuring if integrity or confidentiality services from a mechanism
before a security context has been successfully established remains the
big problem. Someone would have to "guess and configure" it somewhere
in some (still) non-standard way ...
-Martin
Received: from cnri by ietf.org id aa21494; 23 May 97 19:52 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14016;
23 May 97 19:52 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <WAA16372 at pad-thai.cam.ov.com>; Fri, 23 May 1997 22:03:53 GMT
Message-Id: <F0C5060A8699D011A2B100805F14C869C75DDF at RED-75-MSG.dns.microsoft.com>
From: "Mike Swift (NT)" <mikesw at microsoft.com>
To: Martin.Rex at sap-ag.de
Cc: cat-ietf at mit.edu
Subject: RE: Snego & GSS V2
Date: Fri, 23 May 1997 15:02:42 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Precedence: bulk
The way we are approaching this is to have mechanisms that want to
participate in negotiation provide an initialization function that lists
the capabilities of the mechansim. The SPNEGO mechanism on both client
and target can then use this information to make choice about what
mechanisms to use. This is an exentsion of GSS-API, though. Another
option is that when installing a mechanism the installation routine
could publish information about the mechanism for the SPNEGO mechanism
to use. Again, I think these are out of the scope of the protocol
definition.
- Mike
> -----Original Message-----
> From: Martin Rex [SMTP:martin.rex at sap-ag.de]
> Sent: Friday, May 23, 1997 1:29 PM
> To: Mike Swift (NT)
> Cc: cat-ietf at mit.edu
> Subject: Re: Snego & GSS V2
>
>
> To make this work, these bits would have to be sent along with the
> negotiation tokens. One big problem with GSS-API is, that information
> about availability of integrity and confidentiality services can not
> necessesarily be determined before successful security context
> establishment.
>
> I assume that was done so that a basic mechanism could define
> different
> sets of algorithms (QOPs), and it could happen that two different
> implementations did support the same authentication and integrity
> algorithm sets, but different (optional!) confidentiality algorithm
> sets
> (probably due to export control and intelectual property rights issues
> ...).
>
> Not even potential availability can be queried through regular API
> calls (I'm badly missing this functionality myself -- it wouldn't
> be accurate all the time, but most of the time).
>
>
Received: from ietf.org by ietf.org id aa07659; 24 May 97 10:18 EDT
Received: from venera.isi.edu by ietf.org id aa07521; 24 May 97 10:08 EDT
Received: from piglet.dstc.edu.au by venera.isi.edu (5.65c/5.61+local-28)
id <AA23091>; Sat, 24 May 1997 07:04:20 -0700
Received: from alf.dstc.edu.au (zoran at alf.dstc.edu.au [130.102.176.30])
by piglet.dstc.edu.au (8.8.5/8.8.5) with SMTP
id AAA30255; Sun, 25 May 1997 00:01:12 +1000 (EST)
Date: Sun, 25 May 1997 00:01:12 +1000 (EST)
Sender:ietf-request at ietf.org
From: Zoran Milosevic <zoran at dstc.edu.au>
Reply-To: Zoran Milosevic <zoran at dstc.edu.au>
To: enternet at bbn.com
Cc: nmf-objects at nmf.org, tccc at cs.umass.edu, end2end-interest at isi.edu,
cnom at maestro.bellcore.com, commsoft at cc.bellcore.com, ietf at isi.edu,
rem-conf-request at es.net, testnet at canarie.ca
Subject: FINAL Call For Papers - EDOC'97
Message-Id: <Pine.OSF.3.95.970524235348.27963I-100000 at alf.dstc.edu.au>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Dear Colleagues,
Please find enclosed Call for Papers for the First Enterprise
Distributed Object Computing Workshop (EDOC'97). Our sincere apologies
in case you receive this message through multiple mailing lists.
*****************************************************************
CALL FOR PAPERS
The 1st International Enterprise Distributed Object Computing
Workshop (EDOC'97)
October 24-26, 1997,
Marriott Resort, Gold Coast, Australia
http://www.dstc.edu.au/events/edoc97/
Hosted by:
DSTC - Cooperative Research Centre for
Distributed Systems Technology, Australia
Principal Sponsor:
MCI Systemhouse
Co-sponsored by:
IEEE Communications Society - Enterprise Networking
Technical Committee
In cooperation with:
ACM SIGPLAN
Endorsed by:
Object Management Group (OMG)
International Organisation for Standardisation (ISO)
The Institute of Electronics, Information and
Communication Engineers of Japan (IEICE)*
*****************************************************************
EDOC'97 will be followed by the 3rd Asia Pacific Distributed
Solutions Event (DSE97), Oct. 26-29, 1997 at the same venue.
SCOPE:
~~~~~~
Distributed object technology has reached a stage which offers many
new promises for its use in business applications. It brings solutions
to the technical problems which the IT community has faced for many
years: interoperability between heterogeneous hardware and software
systems and evolution of IT systems to support changing business
requirements. The distributed object paradigms, such as CORBA,
ActiveX/DCOM, Java and TINA, as well as the guidelines of the ISO/ITU
standard on Open Distributed Processing (ODP) provide a sound basis
for building enterprise applications. However, in spite of the
benefits which OO, high communication bandwidth and standard
middleware solutions could bring, there are still many problems which
prevent wide use of this technology within and among enterprises.
As a result, the focus of the IT community is gradually shifting
towards providing support for the use of distributed object technology
for a wide range of business applications. This includes having a
commonly accepted enterprise language for the description of enterprise
applications, suitable object models and the underlying distributed
infrastructure, as a 'business bus' for enterprise wide applications.
These topics constitute an Enterprise Distributed Object Computing.
This first International Enterprise Distributed Object Computing
Workshop will bring together experts from different backgrounds
working on various aspects of Enterprise Distributed Object Computing.
A further aim of the event is to promote this important topic within the
Asia-Pacific Region. Due to the increasing interest in this area we
anticipate that we will have a substantial number of good presentations
with plenty of time for discussions.
TOPICS:
~~~~~~~
The topics of the Workshop include, but are not limited to:
- Distributed object architectures, frameworks and patterns
- Enterprise architectures and WWW
- Distributed business objects and components
- ODP enterprise language extensions and refinements
- ODP enterprise language and business process modelling
- Distributed objects and intra and inter-organisational workflow
- Role-based enterprise security
- Distributed objects for electronic commerce
- CSCW support for enterprise interactions and cooperation
- Enterprise policy and management
- Case studies on distributed enterprise systems
- Domain architectures (finance, health, telecommunications)
- Trader and Intelligent Brokers
- Distributed intelligent agents for enterprise systems
- The use of mobile computing in enterprise systems
- Enterprise aspects of Quality of Service
- Architecture Definition Languages and enterprise applications
- Methods for enterprise distributed object computing
IMPORTANT DATES:
~~~~~~~~~~~~~~~~
June 1, 1997: Papers due
August 8, 1997: Notification of acceptance
September 5, 1997: Final papers due
October 24-26, 1997: Workshop date
INFORMATION FOR AUTHORS:
~~~~~~~~~~~~~~~~~~~~~~~~
Papers:
Authors are invited to submit full papers. Papers will be refereed.
The papers presented will be published by the IEEE Computer Society
Press.
While initial submissions can be in any format, it may be more
convenient for authors to use the IEEE Author Guidelines for these
submissions - the final papers will need to comply with the IEEE format.
Final papers should not exceed 12 pages in length, corresponding to
the IEEE format (double column, single spaced, 10 points Times).
The IEEE guidelines for authors are available at:
http://www.dstc.edu.au/events/edoc97/authorguide.html
Submission guidelines:
The preferred method for submission is electronic mail or ftp transfer.
For submission details please have a look at:
http://www.dstc.edu.au/events/edoc97/Sub.html
WORKSHOP ORGANISERS:
~~~~~~~~~~~~~~~~~~~~
General Chair:
Zoran Milosevic (DSTC, Australia)
Program Chairs:
Cris Kobryn (MCI Systemhouse, USA)
Morris Sloman (Imperial College, London, UK)
Program Committee:
Fausto Caneschi (Finsiel S.p.A., Italy)
Eng Chew (Optus, Australia)
Luke O'Connor (IBM Zurich, Switzerland)
Fred Cummins (EDS, USA)
Takeo Hamada (Fujitsu, Japan)
Claudia Linnhoff-Popien (RWTH Aachen, Germany)
Subrata Mazumdar(Bell Labs, USA)
Osamu Miyagishi(NTT, Japan)
Maria Orlowska (The University of Queensland, Australia)
Kerry Raymond (DSTC, Australia)
Roberto Saracco (CSELT, Italy)
Oliver Sims (SSA Object Technology, UK)
Richard Mark Soley (OMG, USA)
Jean-Bernard Stefani (CNET France Telecom, France)
R. Alexander (Sandy) Tyndale-Biscoe, (Birchquest Ltd, UK)
Karl-Heinz Weiss (Public Administration Berlin, Germany)
Bryan Wood (Open-IT, UK)
Douglas Zuckerman (Bellcore, USA)
Local Organising Committee:
Elizabeth Armstrong, DSTC
Andy Bond, DSTC
Emma Crameri, DSTC
Kim Dinh, DSTC
Ron Hickey, DSTC
Jenny MacKay, DSTC
Andry Rakotonirainy, DSTC
VENUE:
~~~~~~
EDOC'97 will be held on the Gold Coast, Queensland, at one of the
Gold Coast's premier venues: Marriott Resort. The Gold Coast is the most
popular tourist destination in Australia. Its glorious sandy beaches
and sub-tropical, though mild climate, attract people from all over
the world. The Gold Coast is located 80 km south of Brisbane, the
capital of Queensland, Australia's Sunshine State.
The Gold Coast offers a wide range of entertainment and sporting
activities, including many beautiful golf courses, fishing and boating
facilities, rainforest bushwalking, excellent restaurants and many
more attractions.
ENQUIRIES AND REGISTRATION DETAILS:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Accommodation (at a discounted conference rate) is available
at the workshop venue as well as at alternative accommodation nearby.
Registration and accommodation details are available at:
http://www.dstc.edu.au/events/edoc97/acco.html
Please email your enquiries to:
edoc-info at dstc.edu.au
Postal address:
Level 7, Gehrmann Laboratories
The University of Queensland, Q4072
Australia
Phone: +61 7 3365 4310, Facsimile: +61 7 3365 4311
RELATED EVENTS:
~~~~~~~~~~~~~~~
October 21-23, 1997 DSOM'97 (Sydney) 8th IFIP/IEEE International
Workshop on Distributed Systems Operations & Management
October 26-29 DSE'97 (Gold Coast) 3rd Asia Pacific
Distributed Solutions Event
November 10-12 OOIS97 (Brisbane) 4th International Conference
On Object-Oriented Information Systems
WWW PAGE:
~~~~~~~~~
Further details for the EDOC'97 event and this Call For Papers can be
found in:
http://www.dstc.edu.au/events/edoc97/
*Awaiting final approval
Received: from cnri by ietf.org id aa05025; 25 May 97 16:15 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa08032; 25 May 97 16:15 EDT
Received: from ietf.org by ietf.org id aa05007; 25 May 97 16:15 EDT
Received: from odb.rhein-main.de by ietf.org id aa04993; 25 May 97 16:15 EDT
Received: from in.rhein-main.de by odb.rhein-main.de with cbsmtp
(Smail3.2 #2) id m0wVjca-0007cWC; Sun, 25 May 1997 22:10:28 +0200 (MET DST)
Received: by incom.rhein-main.de (Smail3.1.29.1 #2)
id m0wVgP6-0006nmC; Sun, 25 May 97 17:44 MET
Message-Id: <m0wVgP6-0006nmC at incom.rhein-main.de>
Sender:iesg-request at ietf.org
From: Winfried Koenig <win at in.rhein-main.de>
Subject: Re: Classless IN-ADDR.ARPA delegation
To: Dave Marquardt <marquard at austin.ibm.com>
Date: Sun, 25 May 1997 17:44:19 +0100 (MET)
Cc: win at in.rhein-main.de, iesg at ietf.org, ietf at ietf.org
In-Reply-To: <199705231312.IAA38798 at mojave.austin.ibm.com> from "Dave Marquardt" at May 23, 97 08:12:24 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 1142
On Fri, 23 May 1997 Dave Marquardt wrote:
>
> On Thu, 22 May 1997 22:00:43 +0100 (MET) Winfried Koenig wrote:
> > The reason is, there are a lot of programs and scripts for
> > DNS support and some of these will break with the character
> > '/' in zone names. Zone names are often used to generate
> > Filenames and the '/' character is used as Unix directory
> > delimiter. ...
>
> So don't use a zone name with a '/' in it to generate zone
> filenames. Or don't use zone names with '/' in them--the way I read
> the draft, that's certainly an administrator's choice.
That's not the problem. Beside for demonstrating broken resolvers
I will never generate zone names with '/' in them. But if this
draft is accepted it will be necessary to advice every naive
administrator with something like:
RFC-XXX describes a way to do IN-ADDR.ARPA delegation on nonoctet
boundaries. But if you don't like to exclude some 10000 Systems
with broken resolvers, you should replace any '/' character
in the zone names with the character '-'.
--
Winfried Koenig, Arendsstrasse 12, D-63075 Offenbach
Phone: +49 69 868707, Mail: <win at in.rhein-main.de>
Received: from cnri by ietf.org id aa05043; 25 May 97 16:15 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa08037; 25 May 97 16:15 EDT
Received: from ietf.org by ietf.org id aa05031; 25 May 97 16:15 EDT
Received: from odb.rhein-main.de by ietf.org id aa05009; 25 May 97 16:15 EDT
Received: from in.rhein-main.de by odb.rhein-main.de with cbsmtp
(Smail3.2 #2) id m0wVjdW-0007cXC; Sun, 25 May 1997 22:11:26 +0200 (MET DST)
Received: by incom.rhein-main.de (Smail3.1.29.1 #2)
id m0wVh3g-00006BC; Sun, 25 May 97 18:26 MET
Message-Id: <m0wVh3g-00006BC at incom.rhein-main.de>
Sender:iesg-request at ietf.org
From: Winfried Koenig <win at in.rhein-main.de>
Subject: Re: Classless IN-ADDR.ARPA delegation
To: Robert Elz <kre at munnari.oz.au>
Date: Sun, 25 May 1997 18:26:16 +0100 (MET)
Cc: win at in.rhein-main.de, iesg at ietf.org, ietf at ietf.org
In-Reply-To: <27457.864385317 at munnari.OZ.AU> from "Robert Elz" at May 23, 97 09:01:57 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 902
On Fri, 23 May 1997 Robert Elz wrote:
>
> I absolutely applaud the use if the '/' in the examples in the draft,
> and would object violently if any form of "name correctness" attempted
> to cause that to be changed. I would not agree to requiring use of the
> '/' anywhere, but this draft requires nothing, it is simply the description
> of a useful technique.
That's not a question of "name correctness". A description of a useful
technique should respect the fact that some 10000 broken resolvers
in the Internet can not resolve PTR RR's from zones with the '/'
character in the zone name.
> Then they ought be fixed. Maybe this draft will provide the impetus.
you may play this game with the students at your university, but there
is no way to force upgrades in the whole Internet.
--
Winfried Koenig, Arendsstrasse 12, D-63075 Offenbach
Phone: +49 69 868707, Mail: <win at in.rhein-main.de>
Received: from ietf.org by ietf.org id aa02842; 27 May 97 10:06 EDT
Received: from ietf.ietf.org by ietf.org id aa01687; 27 May 97 9:42 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
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-mib-06.txt
Date: Tue, 27 May 1997 09:42:37 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705270942.aa01687 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.
Note: This revision reflects comments received during the last call period.
Title : Integrated Services Management Information Base
Author(s) : F. Baker, J. Krawczyk
Filename : draft-ietf-intserv-mib-06.txt
Pages : 29
Date : 05/23/1997
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing the the interface attributes
defined in the Integrated Services Model. Comments should be made to the
Integrated Services Working Group, int-serv at isi.edu.
This memo does not, in its draft form, specify a standard
for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-intserv-mib-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-intserv-mib-06.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-intserv-mib-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970523113203.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-intserv-mib-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-intserv-mib-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970523113203.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04119; 27 May 97 10:21 EDT
Received: from ietf.ietf.org by ietf.org id aa01697; 27 May 97 9:42 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
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-mib-06.txt
Date: Tue, 27 May 1997 09:42:42 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705270942.aa01697 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.
Note: This revision reflects comments received during the last call period.
Title : RSVP Management Information Base
Author(s) : F. Baker, J. Krawczyk
Filename : draft-ietf-rsvp-mib-06.txt
Pages : 80
Date : 05/23/1997
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing the Resource Reservation
Protocol (RSVP) within the interface attributes defined in the Integrated
Services Model. Thus, the Integrated Services MIB is directly relevant to
and cross-referenced by this MIB. Comments should be made to the RSVP
Working Group, rsvp at isi.edu.
This memo does not, in its draft form, specify a standard
for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rsvp-mib-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-mib-06.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rsvp-mib-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970523113552.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rsvp-mib-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-mib-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970523113552.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04120; 27 May 97 10:21 EDT
Received: from ietf.ietf.org by ietf.org id aa01739; 27 May 97 9:42 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-ppp at merit.edu, mobile-ip at smallworks.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-pppext-ipcp-mip-01.txt
Date: Tue, 27 May 1997 09:42:48 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705270942.aa01739 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : Mobile IPv4 Configuration Option for PPP IPCP
Author(s) : J. Solomon, S. Glass
Filename : draft-ietf-pppext-ipcp-mip-01.txt
Pages : 18
Date : 05/23/1997
Mobile IP [RFC 2002] defines media-independent procedures by which a Mobile
Node can maintain existing transport and application-layer connections
despite changing its point-of-attachment to the Internet and without
changing its IP address. PPP [RFC 1661] provides a standard method for
transporting multi-protocol packets over point-to-point links. As
currently specified, Mobile IP Foreign Agents which support Mobile Node
connections via PPP can do so only by first assigning unique addresses to
those Mobile Nodes, defeating one of the primary advantages of Foreign
Agents. This documents corrects this problem by defining the Mobile-IPv4
Configuration Option to the Internet Protocol Control Protocol (IPCP) [RFC
1332]. Using this option, two peers can communicate their support for
Mobile IP during the IPCP phase of PPP. Familiarity with Mobile IP [RFC
2002], IPCP [RFC 1332], and PPP [RFC 1661] 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-pppext-ipcp-mip-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-ipcp-mip-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-ipcp-mip-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970523164000.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-ipcp-mip-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-ipcp-mip-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970523164000.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04118; 27 May 97 10:21 EDT
Received: from ietf.ietf.org by ietf.org id aa01719; 27 May 97 9:42 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-doolan-tdp-spec-01.txt
Date: Tue, 27 May 1997 09:42:45 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705270942.aa01719 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Tag Distribution Protocol
Author(s) : P. Doolan, B. Davie, D. Katz,
Y. Rekhter, E. Rosen
Filename : draft-doolan-tdp-spec-01.txt
Pages : 40
Date : 05/23/1997
An overview of a tag switching architecture is provided in [Rekhter].
This document defines the Tag Distribution Protocol (TDP) referred to
in [Rekhter].
TDP is a two party protocol that runs over a connection oriented transport
layer with guaranteed sequential delivery. Tag Switching Routers use TDP
to communicate tag binding information to their peers. TDP supports
multiple network layer protocols including but not limited to IPv4,
IPv6, IPX and AppleTalk.
We define here the PDUs and operational procedures for this TDP and specify
its transport requirements. We also define aspects of the protocol that are
specific to the case where it is run over an ATM datalink.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-doolan-tdp-spec-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-doolan-tdp-spec-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-doolan-tdp-spec-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970523114211.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-doolan-tdp-spec-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-doolan-tdp-spec-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970523114211.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08800; 27 May 97 11:35 EDT
Received: from ietf.ietf.org by ietf.org id aa08286; 27 May 97 11:27 EDT
To: IETF-Announce: ;
Subject: Call for POC Nominations
Sender:ietf-announce-request at ietf.org
From: Brian E Carpenter <brian at hursley.ibm.com>
Reply-to: pocnom at iab.org
Date: Tue, 27 May 1997 11:27:28 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705271127.aa08286 at ietf.org>
IETF,
The IAB has been requested to appoint two people to the Policy
Oversight Committee (POC) established under the recently signed
DNS Memorandum of Understanding. For full details please
see http://www.iahc.org/gTLD-MoU.html
Although there is continued discussion at the political level
about these matters, the IAB has decided to proceed with these
appointments to avoid loss of time if and when the POC starts up.
One person is to be appointed for one year and a second person
for three years, to allow for rolling replacements in future.
The IAB has decided to appoint persons with strong technical
expertise in DNS and Internet technology and with a strong claim
to have an international outlook. The IAB has further decided
to make an open call for nominations from the IETF community.
Procedure:
1. This message is the call for nominations, which should be sent
to pocnom at iab.org by the closing date of 30 June 1997.
** DO NOT SEND NOMINATIONS AS A REPLY TO THIS MESSAGE; SEND THEM
TO pocnom at iab.org **
2. Each nomination must give the name, affiliation, email address
and phone number of the nominee, plus a brief statement (maximum
10 lines) about the nominee's technical and international credentials.
3. Self-nominations are allowed.
4. The IAB will verify each nominee's willingness to serve for one
or three years.
5. The list of willing nominees will be published by the IAB shortly
after the closing date. Confidential comments from the community will
be solicited. The IAB will then make its two appointments
and announce them within one month.
6. Apart from the above, the IAB will be guided in its deliberations
by the procedures defined in RFC 2027.
7. Nominees must accept that a recall procedure, analagous to that
defined in RFC 2027, may be invoked at any time during their terms.
Note - for future years, the IAB is considering delegating
this task to the normal IETF Nominating and Recall Committee
established under RFC 2027. Comments on this idea are welcome.
Brian Carpenter (IAB Chair) brian at hursley.ibm.com
Received: from ietf.org by ietf.org id aa01893; 27 May 97 17:25 EDT
Received: from ietf.ietf.org by ietf.org id aa01336; 27 May 97 17:17 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: OSPF with Digital Signatures to Experimental
Date: Tue, 27 May 1997 17:17:47 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705271717.aa01336 at ietf.org>
The IESG has reviewed the Internet-Draft "OSPF with Digital Signatures"
<draft-murphy-ospf-signature-03.txt> and recommends that it be published
by the RFC Editor as an Experimental RFC. The IESG contact
person is Joel Halpern.
Received: from ietf.org by ietf.org id aa02204; 27 May 97 17:29 EDT
Received: from ietf.ietf.org by ietf.org id aa02050; 27 May 97 17:26 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: urn-ietf at bunyip.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Document Action: A Trivial Convention for using HTTP in URN
Resolution to Experimental
Date: Tue, 27 May 1997 17:26:58 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705271726.aa02050 at ietf.org>
The IESG has reviewed the Internet-Draft "A Trivial Convention for using
HTTP in URN Resolution" <draft-ietf-urn-http-conv-01.txt> and recommends
that it be published by the RFC Editor as an Experimental RFC. This
document is the product of the Uniform Resource Names Working Group. The
IESG contact persons are Keith Moore and Harald Alvestrand.
Received: from ietf.org by ietf.org id aa03248; 27 May 97 17:44 EDT
Received: from ietf.ietf.org by ietf.org id aa03056; 27 May 97 17:42 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: urn-ietf at bunyip.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Document Action: Resolution of Uniform Resource Identifiers using
the Domain Name System to Experimental
Date: Tue, 27 May 1997 17:42:23 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705271742.aa03056 at ietf.org>
The IESG has reviewed the Internet-Draft "Resolution of Uniform Resource
Identifiers using the Domain Name System" <draft-ietf-urn-naptr-05.txt>
and recommends that it be published by the RFC Editor as an Experimental
RFC. This document is the product of the Uniform Resource Names Working
Group. The IESG contact persons are Keith Moore and Harald Alvestrand.
Received: from ietf.org by ietf.org id aa03459; 27 May 97 17:48 EDT
Received: from ietf.ietf.org by ietf.org id aa03334; 27 May 97 17:45 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: snanaumib at external.cisco.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Protocol Action: Definitions of Managed Objects for APPN to
Proposed Standard
Date: Tue, 27 May 1997 17:45:46 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705271745.aa03334 at ietf.org>
The IESG has approved the Internet-Draft "Definitions of Managed Objects
for APPN" <draft-ietf-snanau-appnmib-04.txt> as a Proposed Standard. This
document is the product of the SNA NAU Services MIB Working Group. The
IESG contact person is Joel Halpern.
Technical Summary
This specification defines an extension to the Management Information
Base (MIB) for use with SNMP-based network management. In
particular, it defines objects for monitoring and controlling network
devices with APPN (Advanced Peer-to-Peer Networking) capabilities.
This memo specifies a MIB module in a manner that is both compliant to
the SNMPv2 SMI, and semantically identical to the SNMPv1 definitions.
Working Group Summary
This document reflects the consensus of the working group. There
were no issues raised during the last call.
Protocol Quality
This MIB was reviewed by Randy Presuhn and Deirdre Kostick.
Received: from ietf.org by ietf.org id aa04499; 27 May 97 18:06 EDT
Received: from ietf.ietf.org by ietf.org id aa04115; 27 May 97 17:59 EDT
To: IETF-Announce: ;
cc: RFC Editor <rfc-editor at isi.edu>,
Internet Architecture Board <iab at isi.edu>, ospf at gated.cornell.edu
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Protocol Action: OSPF Version 2 to Draft Standard
Date: Tue, 27 May 1997 17:59:34 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705271759.aa04115 at ietf.org>
The IESG has approved publication of OSPF Version 2
<draft-ietf-ospf-version2-11.txt> as a Draft Standard. This action
will obsolete RFC1583, currently a Draft Standard.
This document is the product of the Open Shortest Path First IGP
(ospf) Working Group. The IESG contact person is Joel Halpern.
Received: from ietf.org by ietf.org id aa06941; 27 May 97 19:06 EDT
Received: from venera.isi.edu by ietf.org id aa06794; 27 May 97 19:04 EDT
Received: from gomez.cs.pitt.edu by venera.isi.edu (5.65c/5.61+local-28)
id <AA15195>; Tue, 27 May 1997 13:26:01 -0700
Received: from zeus.cs.pitt.edu (zeus.cs.pitt.edu [136.142.79.56]) by gomez.cs.pitt.edu (8.8.3/8.8.3) with ESMTP id QAA09817; Tue, 27 May 1997 16:24:26 -0400 (EDT)
Sender:ietf-request at ietf.org
From: Taieb Znati <znati at cs.pitt.edu>
Received: (from znati at localhost) by zeus.cs.pitt.edu (8.8.3/8.8.3) id QAA07562; Tue, 27 May 1997 16:24:13 -0400 (EDT)
Message-Id: <199705272024.QAA07562 at zeus.cs.pitt.edu>
Subject: DMS97 Call For Participation
To: tccc at cs.umass.edu, osimcast at bbn.com, sc6wg4 at ntd.comsat.com,
hipparch at sophia.inria.fr, reres at laas.fr, prs at masi.ibp.fr,
ieeetcpc at ccvm.sunysb.edu, comswtc at gmu.edu, multicomm at cc.bellcore.com,
giga at tele.pitt.edu, isadsoc at fokus.gmd.de, ctc-members at redbank.tinac.com,
ieee_rtc_list at cs.tamu.edu, enternet at bbn.com, cnom at maestro.bellcore.com,
gcomlist1 at manjaro.ece.iit.edu, comsoc.bog at tab.ieee.org,
sigmedia at bellcore.com, comsoc.tac at tab.ieee.org, comsoc-gicb at ieee.org,
commsoft at cc.bellcore.com, BM-Mist1 at cs.ucdavis.edu,
modern-heuristics at uk.ac.mailbase.ucdavis.edu, alg at comm.toronto.edu,
cellular at dfv.rwth-aachen.edu, cost237-transport at comp.lancs.ac.uk,
testnet at canarie.ca, igawdan at bnr.ca, end2end-interest at isi.edu,
f-troup at codex.cis.upenn.edu, g-troup at dworkin.wustl.edu, ietf at isi.edu,
rem-conf-request at es.net
Date: Tue, 27 May 1997 16:24:12 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
=--=--=--=--=--=--=--= =--=--=--=--=--=--=--=
Call For Participation Call For Participation
=--=--=--=--=--=--=--= =--=--=--=--=--=--=--=
DMS'97
1997 Pacific Workshop on Distributed Multimedia Systems
http://www.ksi.edu/seke/dms97pgm.html
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
July 24-25, 1997
University of British Columbia, Vancouver, Canada
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
DMS'97 is a premier forum where academic researchers, system developers
and practicing engineers from around the world exchange ideas and discuss
current activities in the field of multimedia systems and technology.
Highlights of the Program
=--=--=--=--=--=--=--=--=
* Tutorials and Short Courses
* Invited Talks
* Technical Sessions
* Banquet
* Cruise/Dinner
For full program information consult the following URL:
______ http://www.cs.pitt.edu/DMS97 _________
Received: from ietf.org by ietf.org id aa07877; 28 May 97 9:13 EDT
Received: from proxy.ireste.fr by ietf.org id aa07226; 28 May 97 8:55 EDT
Received: from ireste.ireste.fr (ireste.ireste.fr [193.52.81.10])
by gate.ireste.fr (8.8.4/8.8.4) with SMTP
id OAA06827 for <ietf at ietf.org>; Wed, 28 May 1997 14:55:25 +0200
Received: from afara by ireste.ireste.fr, Wed, 28 May 97 14:53:03 +0200
X-Orig-Sender: djld at ireste.fr
Message-Id: <338C2B19.8C4 at ireste.fr>
Date: Wed, 28 May 1997 14:54:49 +0200
Sender:ietf-request at ietf.org
From: "D. JEULAND" <djeuland at ireste.fr>
X-Mailer: Mozilla 3.01Gold (X11; I; HP-UX A.09.05 9000/712)
Mime-Version: 1.0
To: ietf at ietf.org
Subject: (no subject)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
SUBSCRIBE djeuland at ireste.fr
Received: from ietf.org by ietf.org id aa10085; 28 May 97 9:39 EDT
Received: from ietf.ietf.org by ietf.org id aa09915; 28 May 97 9:33 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: IMAP URL Scheme to Proposed Standard
Reply-to: iesg at ietf.org
Date: Wed, 28 May 1997 09:33:54 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705280933.aa09915 at ietf.org>
The IESG has received a request to consider IMAP URL Scheme
<draft-newman-url-imap-09.txt> as a Proposed Standard. This has been
reviewed in the IETF but is not the product of an IETF Working Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by June 27, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa11097; 28 May 97 9:53 EDT
Received: from ietf.ietf.org by ietf.org id aa10646; 28 May 97 9:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: mailext at list.cren.net
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mailext-new-fields-07.txt
Date: Wed, 28 May 1997 09:49:00 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705280949.aa10646 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working
Group of the IETF.
Title : The Supersedes and Expires e-mail headers
Author(s) : J. Palme
Filename : draft-ietf-mailext-new-fields-07.txt
Pages : 4
Date : 05/27/1997
This memo introduces two new e-mail (RFC 822) headers, Supersedes, and
Expires. The postscript version of this IETF draft shows the differences
from its previous version.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mailext-new-fields-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mailext-new-fields-07.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mailext-new-fields-07.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970527133441.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-new-fields-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-new-fields-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970527133441.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11104; 28 May 97 9:53 EDT
Received: from ietf.ietf.org by ietf.org id aa10609; 28 May 97 9:48 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: find at bunyip.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-find-soif-registry-00.txt
Date: Wed, 28 May 1997 09:48:51 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705280948.aa10609 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Common Indexing Protocol
Working Group of the IETF.
Title : Registration Procedures for SOIF Template Types
Author(s) : T. Hardie
Filename : draft-ietf-find-soif-registry-00.txt
Pages : 5
Date : 05/27/1997
The Summary Object Interchange Format [Ref. 1] was first defined by the
Harvest Project [Ref 2.] in January 1994. SOIF was derived from a
combination of the Internet Anonymous FTP Archives IETF Working Group
(IAFA) templates [Ref 3.] and the BibTeX bibliography format [Ref 4.]. The
combination was originally noted for its advantages of providing a
convenient and intuitive way for delimiting objects within a stream, and
setting apart the URL for easy object access or invocation, while still
preserving compatibility with IAFA templates.
SOIF uses named template types to indicate the attributes which may be
contained within a particular summary object. Within the context of
a single application, private agreement on the definition of template
types has been adequate. As SOIF objects are moved among applications,
however, the need for standard, well-specified, and easily identifiable
template types increases. This need is particularly intense in the context
of query referral, where knowledge of an attribute's definition and the
allowed data types for specific values is crucial. For a discussion of
this in the context of the Common Indexing Protocol, see [Ref. 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-find-soif-registry-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-find-soif-registry-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-find-soif-registry-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970527100233.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-find-soif-registry-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-find-soif-registry-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970527100233.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11108; 28 May 97 9:53 EDT
Received: from ietf.ietf.org by ietf.org id aa10740; 28 May 97 9:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
cc: photuris at majordomo.soscorp.com
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-simpson-photuris-schemes-01.txt
Date: Wed, 28 May 1997 09:49:26 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705280949.aa10740 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Photuris: Extended Schemes and Privacy Protection
Author(s) : P. Karn, W. Simpson
Filename : draft-simpson-photuris-schemes-01.txt
Pages : 8
Date : 05/27/1997
Photuris is a session-key management protocol. Extensible Exchange Schemes
are provided to enable future implementation changes without affecting the
basic protocol. An important improvement in security is provided by
protecting exchanges with encryption.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-simpson-photuris-schemes-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-simpson-photuris-schemes-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-simpson-photuris-schemes-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970527165301.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-simpson-photuris-schemes-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-simpson-photuris-schemes-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970527165301.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11102; 28 May 97 9:53 EDT
Received: from ietf.ietf.org by ietf.org id aa10771; 28 May 97 9:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipngwg-testv2-addralloc-00.txt
Date: Wed, 28 May 1997 09:49:34 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705280949.aa10771 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 IPNG Working Group of the
IETF.
Title : IPv6 Testing Address Allocation
Author(s) : R. Hinden, R. Fink, J. Postel
Filename : draft-ietf-ipngwg-testv2-addralloc-00.txt
Pages : 4
Date : 05/27/1997
This document describes an allocation plan for IPv6 addresses to be used in
testing IPv6 prototype software. These addresses are temporary and will be
reclaimed in the future. Any IPv6 system using these addresses will have
to renumber at some time in the future. These addresses will not to be
routable in the Internet other than for IPv6 testing.
This document is intended to replace RFC1897 "IPv6 Testing Address
Allocation", January 1996. RFC1897 will become historic.
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-ipngwg-testv2-addralloc-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-testv2-addralloc-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipngwg-testv2-addralloc-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970527174021.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-testv2-addralloc-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-testv2-addralloc-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970527174021.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11098; 28 May 97 9:53 EDT
Received: from ietf.ietf.org by ietf.org id aa10667; 28 May 97 9:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-palme-autosub-02.txt
Date: Wed, 28 May 1997 09:49:06 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705280949.aa10667 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The auto-submitted e-mail header fields
Author(s) : J. Palme
Filename : draft-palme-autosub-02.txt
Pages : 3
Date : 05/27/1997
This memo introduces one new e-mail (RFC 822) header field with the
name Auto-Submitted.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-palme-autosub-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-palme-autosub-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-palme-autosub-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970527133929.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-palme-autosub-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-palme-autosub-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970527133929.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11103; 28 May 97 9:53 EDT
Received: from ietf.ietf.org by ietf.org id aa10628; 28 May 97 9:48 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: http-wg at cuckoo.hpl.hp.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-http-negotiation-02.txt
Date: Wed, 28 May 1997 09:48:56 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705280948.aa10628 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Transfer Protocol
Working Group of the IETF.
Title : Transparent Content Negotiation in HTTP
Author(s) : K. Holtman, A. Mutz
Filename : draft-ietf-http-negotiation-02.txt
Pages : 44
Date : 05/27/1997
HTTP allows web site authors to put multiple versions of the same
information under a single URL. Transparent content negotiation is a
mechanism, layered on top of HTTP, for automatically selecting the best
version when the URL is accessed. This enables the smooth deployment of
new web data formats and markup tags.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-http-negotiation-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-negotiation-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-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.
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: <19970527133031.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-negotiation-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-negotiation-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970527133031.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11095; 28 May 97 9:53 EDT
Received: from ietf.ietf.org by ietf.org id aa10731; 28 May 97 9:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
cc: photuris at majordomo.soscorp.com
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-simpson-photuris-12.txt
Date: Wed, 28 May 1997 09:49:23 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705280949.aa10731 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Photuris: Session Key Management Protocol
Author(s) : P. Karn, W. Simpson
Filename : draft-simpson-photuris-12.txt
Pages : 69
Date : 05/27/1997
Photuris is a session-key management protocol intended for use with
the IP Security Protocols (AH and ESP). This document defines
the basic protocol mechanisms.
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-simpson-photuris-12.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-simpson-photuris-12.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-simpson-photuris-12.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970527165610.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-simpson-photuris-12.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-simpson-photuris-12.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970527165610.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16255; 28 May 97 11:55 EDT
Received: from fw.reyrey.com by ietf.org id aa16154; 28 May 97 11:54 EDT
Received: by fw.reyrey.com; id LAA03118; Wed, 28 May 1997 11:43:08 -0400 (EDT)
Received: from mailgate.reyrey.com(168.207.1.211) by fw.reyrey.com via smap (3.2)
id xma003097; Wed, 28 May 97 11:43:01 -0400
Received: (from mailgate at localhost) by mailgate.reyrey.com (951211.SGI.8.6.12.PATCH1042/8.6.12) id LAA19540; Wed, 28 May 1997 11:45:44 -0400
Received: by h-or06nt01.or06.reyrey.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5)
id <01BC6B44.2D1C5170 at h-or06nt01.or06.reyrey.com>; Wed, 28 May 1997 08:50:21 -0700
Message-ID: <c=US%a=_%p=Reynolds_?_Reyno%l=H-OR06NT01-970528155019Z-13112 at h-or06nt01.or06.reyrey.com>
Sender:ietf-request at ietf.org
From: "Wheeler, Jesse W" <jesse_wheeler at reyrey.com>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Cc: "'bernarda at microsoft.com'" <bernarda at microsoft.com>
Subject: The Network Access Identifier - Draft Comments
Date: Wed, 28 May 1997 08:50:19 -0700
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Bernard/IETF,
My Comments on the following currently submitted IETF RFC Draft:
The proposed draft looks like a promising idea in the virtual TCP/IP
tunneling
arena. The only problems/conflicts that I have over the proposed
standard is,
the NAI token used to describe the user that is from the host service
looks too
much like a standard Internet e-mail address.. I could see where an end
user or
perhaps, even software that is used for e-mail purposes could get
confused.
Perhaps a newly created delimiter is in order to distinguish between the
two?
---------------------------------------------------
Jesse W. Wheeler
QA/DOC
Reynolds and Reynolds
HSD Portland Operations
Email: Jesse_Wheeler at reyrey.com
Pager: (503) 727-8792
--------------------------------------------------------------------
>Title : The Network Access Identifier
>Author(s) : B. Aboba
>Filename : draft-ietf-roamops-nai-03.txt
>Pages : 4
>Date : 05/22/1997
>BNF for the NAI
>
>The grammar for the NAI is given below, using the augmented BNF nota-
>tion described in reference [9].
>
>NAI = USERNAME "@" FQDN
>FQDN = token "." token *[ "." token ]
>USERNAME = token
>
>Examples of valid Network Access Identifiers include:
>
> fred at bigco.com
> nancy at eng.bigco.edu
>
>Examples of invalid Network Access Identifiers include:
>
> bigco
> howard.edu
> fred at bigco.com@smallco.com
> bigco!fred at smallco.com
> bigco%fred at smallco.com
---------------------------------------------------
Jesse W. Wheeler
QA/DOC
Reynolds and Reynolds
HSD Portland Operations
Email: Jesse_Wheeler at reyrey.com
Voice: (503) 641-5500/Ext. 1421
Pager: (503) 727-8792
--------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa17502; 28 May 97 12:20 EDT
Received: from [200.246.167.105] by ietf.org id aa17421; 28 May 97 12:19 EDT
Received: from tucows.alphanet.com.br (andre at tucows.alphanet.com.br [200.246.167.105]) by tucows.alphanet.com.br (8.7.5/8.7.3) with SMTP id NAA21581; Wed, 28 May 1997 13:18:09 -0300
Date: Wed, 28 May 1997 13:18:08 -0300 (EST)
Sender:ietf-request at ietf.org
From: Andre Correa <andre at tucows.alphanet.com.br>
To: "D. JEULAND" <djeuland at ireste.fr>
cc: ietf at ietf.org
Subject: Re: (no subject)
In-Reply-To: <338C2B19.8C4 at ireste.fr>
Message-ID: <Pine.LNX.3.93.970528131724.21578A-100000 at tucows.alphanet.com.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Please read the mailling list FAQ before trying to subscribe to a
list. It is the wrong address. NetQuet.
<Andre>
**********************************************
<Andre Correa>
E-Mail: andre.correa at pobox.com
Finger: andre.correa at pobox.com
IRC: meandyou > @#sampa igc.dal.net
IRC: meandyou > IRCop irc.alphanet.com.br
Home Page: http://www.pobox.com/~andre.correa/
**********************************************
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAzOCPRcAAAEEAMREqeDuB3F8RiygJQpOAlYrjNg00I9HTmrubN+S/b92cgFk
wnntIdODsrVzkH+AFp+DtfAFMIxUkpyPoKgbZZsGBl/jIbZQKJt9DLqr+KhUCNZF
uH3rb+eCCl4O20WD0xc/vRQyWuKOe7Aov2cIrr+5gyttUvzKXbtXCwEYW0lNAAUR
tCVBbmRyZSBDb3JyZWEgPGFuZHJlLmNvcnJlYUBwb2JveC5jb20+iQCVAwUQM4I9
F7tXCwEYW0lNAQHpiQP/WOiTmRGACc0qQlB56LtPlyzldaCQBev15RQqzaadYZ7z
Eh6CzCg79tczDe3NOzqY3vh8vPWciwKpg377GipJMIaHQL1EqU+WgqKEUXr5MM4d
qg9t++8WHc5lfq8PhOhwJE+IUZmbzXt0Tc+E7nuDkbl2yngeL2bkhNMlEUZEgrU=
=OmNV
-----END PGP PUBLIC KEY BLOCK-----
On Wed, 28 May 1997, D. JEULAND wrote:
> SUBSCRIBE djeuland at ireste.fr
>
Received: from cnri by ietf.org id aa20828; 28 May 97 13:17 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09776;
28 May 97 13:16 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <PAA21608 at pad-thai.cam.ov.com>; Wed, 28 May 1997 15:46:21 GMT
Date: Wed, 28 May 1997 11:46:17 -0400
Message-Id: <199705281546.LAA00372 at rsts-11.mit.edu>
To: Martin.Rex at sap-ag.de
Cc: mikesw at microsoft.com, cat-ietf at mit.edu
In-Reply-To: <199705232054.AA02890 at sap-ag.de> (message from Martin Rex on Fri,
23 May 1997 16:29:19 -0400 (EDT))
Subject: Re: Snego & GSS V2
From: tytso at mit.edu
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Martin Rex <martin.rex at sap-ag.de>
Date: Fri, 23 May 1997 16:29:19 -0400 (EDT)
One big problem with GSS-API is, that information
about availability of integrity and confidentiality services can not
necessesarily be determined before successful security context
establishment.
Hmm.... I could imagine some mechanisms where the availability of
integrity and confidentiality is dependent on the authenticated identity
of the initiator and/or target (i.e., initiator is in America, target is
in France ---> no confidentialty). Depending on where the govermental
restrictions are implemented (i.e., perhaps in the KDC or the Domain
Controller), it may not be possible to know the values until after the
security context is fully negotiated....
- Ted
Received: from cnri by ietf.org id aa25600; 28 May 97 15:12 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11324;
28 May 97 15:12 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <RAA03231 at pad-thai.cam.ov.com>; Wed, 28 May 1997 17:38:08 GMT
To: tytso at mit.edu
Cc: Martin.Rex at sap-ag.de, mikesw at microsoft.com, cat-ietf at mit.edu
Subject: Re: Snego & GSS V2
References: <199705281546.LAA00372 at rsts-11.mit.edu>
From: Marc Horowitz <marc at cygnus.com>
Date: 28 May 1997 13:38:03 -0400
In-Reply-To: tytso at MIT.EDU's message of Wed, 28 May 1997 11:46:17 -0400
Message-Id: <t53n2pfa45g.fsf at rover.cygnus.com>
Lines: 20
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
tytso at MIT.EDU writes:
>> Hmm.... I could imagine some mechanisms where the availability of
>> integrity and confidentiality is dependent on the authenticated identity
>> of the initiator and/or target (i.e., initiator is in America, target is
>> in France ---> no confidentialty). Depending on where the govermental
>> restrictions are implemented (i.e., perhaps in the KDC or the Domain
>> Controller), it may not be possible to know the values until after the
>> security context is fully negotiated....
Perhaps pnego (I've given up on "S" :-) should be able to restart with
a second mechanism, in case the first one ends up being undesirable,
or fails from the start. If the client and server share two
acceptable mechanisms, and the more preferable one fails for some
reason or doesn't support a necessary capability, automatic fallback
to the second would be a nice feature. There's no good reason to
force the application to do the dirty work, that's what negotiation is
for.
Marc
Received: from cnri by ietf.org id aa02093; 28 May 97 17:19 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12907;
28 May 97 17:19 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <TAA11591 at pad-thai.cam.ov.com>; Wed, 28 May 1997 19:00:09 GMT
Message-Id: <199705281859.AA02946 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: Snego & GSS V2
To: Marc Horowitz <marc at cygnus.com>, tytso at mit.edu
Date: Wed, 28 May 1997 20:58:46 +0200 (MESZ)
Cc: cat-ietf at mit.edu, mikesw at microsoft.com
In-Reply-To: <t53n2pfa45g.fsf at rover.cygnus.com> from "Marc Horowitz" at May 28, 97 01:38:03 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Marc Horowitz wrote:
>
> tytso at MIT.EDU writes:
>
> >> Hmm.... I could imagine some mechanisms where the availability of
> >> integrity and confidentiality is dependent on the authenticated identity
> >> of the initiator and/or target (i.e., initiator is in America, target is
> >> in France ---> no confidentialty). Depending on where the govermental
> >> restrictions are implemented (i.e., perhaps in the KDC or the Domain
> >> Controller), it may not be possible to know the values until after the
> >> security context is fully negotiated....
In the scenario Ted mentions, one side *does* know in advance that it
will not support confidentiality, which would be enough for a negotiation
that respects requirements.
In the scenario I mentioned, where the intersection of optional
confidentiality algorithms for a mechanism is empty because of export
control or intellectual property rights issues, the UNavailability of
confidentiality for the security context will not be known until after
context establishment. (since both do support at least one
confidentiality algorithm for the selected mechanism).
>
> Perhaps pnego (I've given up on "S" :-) should be able to restart with
> a second mechanism, in case the first one ends up being undesirable,
> or fails from the start. If the client and server share two
> acceptable mechanisms, and the more preferable one fails for some
> reason or doesn't support a necessary capability, automatic fallback
> to the second would be a nice feature. There's no good reason to
> force the application to do the dirty work, that's what negotiation is
> for.
This will cause a delay and overhead penalty for every context establishment.
As I said, the knowledge of potential availability of a feature will
be sufficient for most cases. So it would be a good idea to check
potential availability against requirements to reorder (or select from)
the preference list.
As I understand it, Mike Swift didn't like the current spnego spec
how it "regulates" that the acceptor should use his mech preference
list and the one from the client and find the mechanism and NOT use
anything else for this decision, like availability of integrity
or confidentiality. (plus in some way: not being able to request
these features).
Adding fallback negotiation cycles like you propose might be
another nice feature, but it would increase the complexity of spnego
even more. Anyway, an automatic fallback negotiation when necessary
capabilities aren't available would require a method of specifying
which capabilities are to be considered a requirement (opposed to
the current "nice-to-have" req_flags), and the two features
integrity and confidentiality would have to be included in
the list of *required* features -- currently gss_init_sec_context()
only allows to specify feature desires; confidentiality and integrity
not among them.
Add the capability to *require* features for negotiation and
drop the word "simple" from spnego.
Add the capability to do automatic fallback negotiation to accomodate
required features when the unavailability is detected only after
context establishment and add the word "complex" to pnego. ;-)
-Martin
Received: from cnri by ietf.org id aa03666; 28 May 97 18:04 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13435;
28 May 97 18:04 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <UAA19403 at pad-thai.cam.ov.com>; Wed, 28 May 1997 20:15:59 GMT
To: Martin.Rex at sap-ag.de
Cc: tytso at mit.edu, cat-ietf at mit.edu, mikesw at microsoft.com
Subject: Re: Snego & GSS V2
References: <199705281859.AA02946 at sap-ag.de>
From: Marc Horowitz <marc at cygnus.com>
Date: 28 May 1997 16:15:39 -0400
In-Reply-To: Martin Rex's message of Wed, 28 May 1997 20:58:46 +0200 (MESZ)
Message-Id: <t53g1v79wus.fsf at rover.cygnus.com>
Lines: 45
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
Martin Rex <martin.rex at sap-ag.de> writes:
>> This will cause a delay and overhead penalty for every context establishment.
How? If the first context setup succeeds, you don't need any extra
round trips. If it doesn't, you send some sort of restart message.
There's a delay, but succeeding eventually is better than failing.
In the common case, everything will work fine.
>> As I said, the knowledge of potential availability of a feature will
>> be sufficient for most cases. So it would be a good idea to check
>> potential availability against requirements to reorder (or select from)
>> the preference list.
You can do this in addition to failing over as I described.
>> Adding fallback negotiation cycles like you propose might be
>> another nice feature, but it would increase the complexity of spnego
>> even more. Anyway, an automatic fallback negotiation when necessary
>> capabilities aren't available would require a method of specifying
>> which capabilities are to be considered a requirement (opposed to
>> the current "nice-to-have" req_flags),
Yes, it would. This could be done via an extension function or
something. The idea is that interoperability on the wire can be
maintained, which is the most important thing. Interoperability at
the API layer can come later.
The idea is that a simple client can just blindly follow the server's
direction. The heuristics can be in the server, which is relatively
easy to upgrade.
>> Add the capability to *require* features for negotiation and
>> drop the word "simple" from spnego.
Like I said, I'm prepared to do that. I prefer "useful" over "simple"
any day.
>> Add the capability to do automatic fallback negotiation to accomodate
>> required features when the unavailability is detected only after
>> context establishment and add the word "complex" to pnego. ;-)
Fallback at the client is easy. The SAP server is already complex :-)
Marc
Received: from cnri by ietf.org id aa06093; 28 May 97 18:59 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14095;
28 May 97 18:59 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <VAA27595 at pad-thai.cam.ov.com>; Wed, 28 May 1997 21:31:27 GMT
Message-Id: <199705282130.AA15942 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: Snego & GSS V2
To: Marc Horowitz <marc at cygnus.com>
Date: Wed, 28 May 1997 17:29:31 -0400 (EDT)
Cc: cat-ietf at mit.edu
In-Reply-To: <t53g1v79wus.fsf at rover.cygnus.com> from "Marc Horowitz" at May 28, 97 04:15:39 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Marc Horowitz wrote:
>
> Martin Rex <martin.rex at sap-ag.de> writes:
>
> >> This will cause a delay and overhead penalty for every context establishment.
>
> How? If the first context setup succeeds, you don't need any extra
> round trips. If it doesn't, you send some sort of restart message.
> There's a delay, but succeeding eventually is better than failing.
> In the common case, everything will work fine.
I'm sorry, I definitely failed to write what I was thinking of:
In case one would not configure the mechanisms' (potential) features in
advance (currently in some non-standard fashion) and use it immediately
for selection of a suitable common mechanism, but instead rely only on
the (supported) rec_flags received from a successful context establishment,
then the fallback can be much more expensive.
In the worst-case situation, very portable applications are very
unspecific about their target and have to go through several fallback
cycles every time a connection is established. This results in
a "very low transaction rate". In this case the user/administrator
of the application should be given both, clear hint and option
to adjust the configuration or supply more specific information
to the application how to feed the GSS-API negotiation engine
adequately.
>
> >> As I said, the knowledge of potential availability of a feature will
> >> be sufficient for most cases. So it would be a good idea to check
> >> potential availability against requirements to reorder (or select from)
> >> the preference list.
>
> You can do this in addition to failing over as I described.
>
> >> Adding fallback negotiation cycles like you propose might be
> >> another nice feature, but it would increase the complexity of spnego
> >> even more. Anyway, an automatic fallback negotiation when necessary
> >> capabilities aren't available would require a method of specifying
> >> which capabilities are to be considered a requirement (opposed to
> >> the current "nice-to-have" req_flags),
>
> Yes, it would. This could be done via an extension function or
> something. The idea is that interoperability on the wire can be
> maintained, which is the most important thing. Interoperability at
> the API layer can come later.
See my proposal. Thinking about it, the negotiation constraints
should be transferred seperately from the feature request of
gss_init_sec_context(). But even negotiation constraining feature
requests should prevent a successful context establishment without
these features.
>
> The idea is that a simple client can just blindly follow the server's
> direction. The heuristics can be in the server, which is relatively
> easy to upgrade.
Careful. If you had seen some of the servers that I know, which people
are growing for specific areas, you wouldn't be so quick to call
it 'easy'. (You might even start wondering about the 'easier' relation).
>
> >> Add the capability to *require* features for negotiation and
> >> drop the word "simple" from spnego.
>
> Like I said, I'm prepared to do that. I prefer "useful" over "simple"
> any day.
>
Me too. And since there appears to be a strong desire for several CAT
participants to create a Highlander (i.e. the one and only negotiation
mechanism), "useful" should be a design goal.
-Martin
Received: from cnri by ietf.org id aa06100; 28 May 97 18:59 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14100;
28 May 97 18:59 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <UAA20523 at pad-thai.cam.ov.com>; Wed, 28 May 1997 20:27:16 GMT
Date: Wed, 28 May 1997 22:26:48 +0200
Message-Id: <199705282026.WAA30704 at p18509.wdf.sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
To: cat-ietf at mit.edu
Cc: tytso at mit.edu, mikesw at microsoft.com, marc at cygnus.com
Precedence: bulk
D.Pinkas at frcl.bull.fr, Martin.Rex at sap-ag.de
Subject: negotiation constraints for S(P)NEGO
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Here's a proposal to add negotiation constraints to s(p)nego:
To have additional negotiation constraints be considered by spnego,
add (a) new input Parameter(s) to GSS_Get_neg_mechs and (a) new
output Parameter(s) to GSS_Set_neg_mechs (compare rfc2078 2.2.1;
the C-bindings combine all flags into a single bitfield argument):
A.1. GSS_Get_neg_mechs call
Input:
< cred_handle OCTET STRING - NULL specifies default credentials
> cred_handle CREDENTIAL HANDLE - NULL specifies default credentials
Outputs:
major_status INTEGER,
minor_status INTEGER,
mech_option_set SET OF OBJECT IDENTIFIER
+ deleg_req_state BOOLEAN
+ mutual_req_state BOOLEAN
+ replay_det_req_state BOOLEAN
+ sequence_req_state BOOLEAN
+ anon_req_state BOOLEAN
+ trans_req_state BOOLEAN
+ prot_ready_req_state BOOLEAN
+ conf_avail_req_state BOOLEAN
+ integ_avail_req_state BOOLEAN
Return major_status codes :
< GSS_COMPLETE indicates that the set of security mechanism
> GSS_S_COMPLETE indicates that the set of security mechanism
options available for negotiation has been returned in
mech_option_set.
< GSS_FAILURE indicates that the requested operation could not
> GSS_S_FAILURE indicates that the requested operation could not
be performed for reasons unspecified at the GSS-API level.
Allows callers to determine the set of security mechanism options
available for negotiation. This call is intended for support of
specialised callers who need to reduce the set of negotiable security
mechanism options from the set of supported security mechanisms
available to the caller (based on available credentials).
+ The return state values for features indicates if the availability of
+ this features is considered more important than the order of the
+ mechanisms of the preference list. For accepting a negotiation this
+ means that the availability of a feature will take precedence in
+ the selection process; for initiating a negotiation this means
+ that the requested features will be included in the initial
+ negotiation token for consideration by the context acceptor.
+
+ Since there is currently no standardized way to inquire availability
+ of such features, support of these additional negotiation
+ constraints is optional. When an implementation of snego doesn't
+ support it, it should always return FALSE for all *_req_state
+ indicators and ignore incoming indicators for the negotiation.
+
+ Implementations of spnego that do support the additional negotiation
+ constraints, know about their mechanisms features and allow external
+ preconfiguration of such constraints should reflect any constraints
+ that are in effect through the respective indicators.
Note: The GSS_Indicate_mechs() function indicates the full set of mechanism
< types available on the local system. Since this call does not use a
< credential handle as an input parameter, the returned set is not
> types available on the local system. Since this call does not require a
> valid credential handle as an input parameter, the returned set is not
necessarily available for all credentials.
A.2. GSS_Set_neg_mechs call
Input:
< cred_handle OCTET STRING - NULL specifies default credentials
> cred_handle CREDENTIAL HANDLE - NULL specifies default credentials
mech_option_set SET OF OBJECT IDENTIFIER
+ deleg_req_flag BOOLEAN
+ mutual_req_flag BOOLEAN
+ replay_det_req_flag BOOLEAN
+ sequence_req_flag BOOLEAN
+ anon_req_flag BOOLEAN
+ trans_req_flag BOOLEAN
+ prot_ready_req_flag BOOLEAN
+ conf_avail_req_flag BOOLEAN
+ integ_avail_req_flag BOOLEAN
Outputs:
major_status INTEGER,
minor_status INTEGER,
Return major_status codes :
< GSS_COMPLETE indicates that the set of security mechanisms
> GSS_S_COMPLETE indicates that the set of security mechanisms
available for negotiation has been set to mech_option_set.
+ GSS_S_UNAVAILABLE indicates that this spnego implementation
+ does not know about the features available from its mechanisms
+ or does not implement the additional negotiation constraints.
+? GSS_S_UNAUTHORIZED if the policy does not allow the specific
+? requested order of mechanisms, or the implicit reordering
+? implied by requesting a specific feature.
< GSS_FAILURE indicates that the requested operation could not be
> GSS_S_FAILURE indicates that the requested operation could not be
performed for reasons unspecified at the GSS-API level.
Allows callers to specify the set of security mechanism options that
may be negotiated with a particular credential: A NULL mech_option_set
specifies that only the default mech_type with the default option is
available for the GSS-API implementation. This call is intended for
support of specialised callers who need to restrict the set of
negotiable security mechanism options from the set of all security
mechanism options available to the caller (based on available
credentials). Note that if more than one mechanism is specified in
mech_option_set, the order in which those mechanisms are specified
implies a relative mechanism preference for the target.
+ Besides the mechanism preference list, an implementation of spnego
+ may support additional negotiation constraints based on the
+ availability of security context features. An application may
+ indicate its preference of features over the order of mechanisms
+ on the mechanism preference list by using the respective request
+ flag. Preconfiguration of feature requests may also be supported,
+ but is expected to affect the default mechanism preference list only.
+
+ When the additional negotiation constraints are supported, they should
+ immediately be used to rearrange the mechanism preference list based
+ on the local knowledge about the features of the contained mechanisms.
+ This way, an established security context will more likely meet the
+ expectations of the caller, even if the peer doesn't supply or doesn't
+ implement and therefore ignore additional negotiation constraints.
===========
Besides the additional features, I've also applied small editorial
changes (marked with <>) that should be changed anyway.
An observation to GSS_Set_neg_mechs(): The NULL mech_option_set
should ONLY be allowed for NON-NULL cred_handles.
Comments on this proposals will be appreciated
(as well as corrections/changes).
-Martin
Received: from cnri by ietf.org id aa11052; 28 May 97 20:59 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15218;
28 May 97 20:59 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <XAA09967 at pad-thai.cam.ov.com>; Wed, 28 May 1997 23:09:59 GMT
Date: Wed, 28 May 1997 19:09:53 -0400
Message-Id: <9705282309.AA00943 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Martin.Rex at sap-ag.de
Cc: marc at cygnus.com, cat-ietf at mit.edu, mikesw at microsoft.com
In-Reply-To: Martin Rex's message of Wed, 28 May 1997 20:58:46 +0200 (MESZ),
<199705281859.AA02946 at sap-ag.de>
Subject: Re: Snego & GSS V2
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Martin Rex <martin.rex at sap-ag.de>
Date: Wed, 28 May 1997 20:58:46 +0200 (MESZ)
In the scenario Ted mentions, one side *does* know in advance that it
will not support confidentiality, which would be enough for a negotiation
that respects requirements.
No, not necessarily. The determination of whether or not confidentailty
will be granted or not might be decided by a third party, such as the
KDC or Domain controller. In fact, I could imagine a protocol where you
the mechanism queries the French Secret Service to get permission to
turn on confidentailty before doing so. :-)
We could explicitly declare such mechanisms out of scope, and make the
assumption that one side will know in advance whether or not
confidentialty will be supported, but let's consciously make that
decision.
- Ted
Received: from ietf.org by ietf.org id aa22764; 29 May 97 0:03 EDT
Received: from venera.isi.edu by ietf.org id aa22545; 28 May 97 23:57 EDT
Received: from kcnet.com by venera.isi.edu (5.65c/5.61+local-28)
id <AA16665>; Wed, 28 May 1997 20:53:10 -0700
Received: from newman (pm3x26.kcnet.com [206.102.129.91])
by kcnet.com (8.8.5/8.8.5) with SMTP id WAA20761
for <ietf at isi.edu>; Wed, 28 May 1997 22:49:53 -0500
Message-Id: <199705290349.WAA20761 at kcnet.com>
Comments: Authenticated sender is <me at pop.netaddress.com>
Sender:ietf-request at ietf.org
From: "Justin B. Newman" <me at usa.net>
To: ietf at isi.edu
Date: Wed, 28 May 1997 22:49:52 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: the case of the vanishing e-mail
Reply-To: me at usa.net
Priority: normal
X-Mailer: Pegasus Mail for Win32 (v2.52)
Source-Info: From (or Sender) name not authenticated.
Recently, I have had a complete inability to send e-mail to a
particular aol subscriber from usa.net. This spans multiple usa.net
accounts, both sending from their web interface and their SMTP host
and another SMTP host with their return address. The aol account is
known to be working as e-mails from various UNIX machines all arive
in good order. Any ideas what's going wrong? I write this remembering
some discussions about usa.net and aol doing some mail filtering....
and aol is on my mind because of Steve Case's appearance on the
National Press Club today. A well done speech and q/a session, I
might add.
I recognize that there may be a more appropriate place for this
question. If you believe there to be such, your guidance will be much
appreciated.
Thanks,
-jbn
Received: from cnri by ietf.org id aa06686; 29 May 97 9:00 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa05390;
29 May 97 9:00 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <LAA15866 at pad-thai.cam.ov.com>; Thu, 29 May 1997 11:19:05 GMT
Message-Id: <338DE495.465A at frcl.bull.fr>
Date: Thu, 29 May 1997 13:18:29 -0700
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
Mime-Version: 1.0
To: CAT-IETF WG <cat-ietf at mit.edu>
Subject: Re: Snego & GSS V2
References: <9705282309.AA00943 at dcl.MIT.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
SNEGO, PNEGO, SPNEGO, CNEGO or CPNEGO ? with C=Complex :-)
The negotiation mechanism described in the current draft is giving
exactly the same features as the GSS-API V2. In particular, it is not
possible to know in advance whether confidentiality and integrity will
be available (although most mechanisms support this feature). The
paradigm is: if you do not like what you got, you destroy the context.
The basic question is whether we want (1) to stay like this, (2) enrich
the current functionality of GSS-API V2 so that it becomes available on
GSS-API V2 or (3) enrich the current functionality of SPNEGO so that it
becomes available on CPNEGO only.
Martin as made a proposal along the option (3) that applies to the
optional APIs described in the annex of SPNEGO. If we follow that
proposal, that will end-up with flags that are present in the protocols
that can only be set by these APIs. This would thus make sense to
consider the APIs in the main body of SPNEGO or ... of GSS-API V2+.
Note : If we enrich, for backward compatibility, GSS_init_sec_context
should be kept unchanged and thus it would make sense to have new APIs.
I would favor two additional APIs, independent from GSS_Get_neg_mechs
and GSS_Set_neg_mechs that would allow to specify the flags and make it
part of GSS-API V2+ so that the functionality becomes available whether
a precise mech is specified or the negotiation mechanism is specified.
The consequence on SPNEGO would be to add another structure in the
negotiation token like :
MandatoryServices ::= BIT STRING {
delegFlag (0),
mutualFlag (1),
replayFlag (2),
sequenceFlag (3),
anonFlag (4),
confFlag (5),
integFlag (6)
}
Regards,
Denis
--
Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from ietf.org by ietf.org id aa09529; 29 May 97 9:56 EDT
Received: from ietf.ietf.org by ietf.org id aa08612; 29 May 97 9:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-mogul-http-revalidate-01.txt
Date: Thu, 29 May 1997 09:43:37 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705290943.aa08612 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Forcing HTTP/1.1 proxies to revalidate responses
Author(s) : J. Mogul
Filename : draft-mogul-http-revalidate-01.txt
Pages : 10
Date : 05/28/1997
The HTTP/1.1 specification [1] currently defines a ``proxy-revalidate''
Cache-control directive, which forces a proxy to revalidate a stale
response before using it in a reply. There is no mechanism defined that
forces a proxy, but not an end-client, to revalidate a fresh response. The
lack of such a mechanism is due to an error in drafting RFC2068, and
appears to create problems for use of the Authorization header, the Digest
Access Authentication extension [2], the State Management Mechanism [3],
and several other proposed extensions. This document discusses the problem
and several possible solutions, and proposes to add a new ``s-maxage''
directive as the best available solution.
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-mogul-http-revalidate-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-mogul-http-revalidate-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-mogul-http-revalidate-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970528114050.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-mogul-http-revalidate-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-mogul-http-revalidate-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970528114050.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09528; 29 May 97 9:56 EDT
Received: from ietf.ietf.org by ietf.org id aa08687; 29 May 97 9:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-myers-auth-sasl-11.txt
Date: Thu, 29 May 1997 09:43:50 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705290943.aa08687 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Simple Authentication and Security Layer (SASL)
Author(s) : J. Myers
Filename : draft-myers-auth-sasl-11.txt
Pages : 15
Date : 05/28/1997
This document describes a method for adding authentication support to
connection-based protocols. To use this specification, a protocol includes
a command for identifying and authenticating a user to a server and for
optionally negotiating protection of subsequent protocol interactions. If
its use is negotiated, a security layer is inserted between the protocol
and the connection. This document describes how a protocol specifies such
a command, defines several mechanisms for use by the command, and defines
the protocol used for carrying a negotiated security layer over the
connection.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-myers-auth-sasl-11.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-myers-auth-sasl-11.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-myers-auth-sasl-11.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970528140849.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-myers-auth-sasl-11.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-myers-auth-sasl-11.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970528140849.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09523; 29 May 97 9:56 EDT
Received: from ietf.ietf.org by ietf.org id aa08803; 29 May 97 9:44 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: stdguide at midnight.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-stdguide-ops-04.txt
Date: Thu, 29 May 1997 09:44:17 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705290944.aa08803 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 Guide for Internet Standards
Writers Working Group of the IETF.
Title : Guide for Internet Standards Writers
Author(s) : G. Scott
Filename : draft-ietf-stdguide-ops-04.txt
Pages : 19
Date : 05/28/1997
This document is a guide for Internet standard writers. It defines those
characteristics that make standards coherent, unambiguous, and easy to
interpret. Also, it singles out usage believed to have led to unclear
specifications, resulting in non-interoperable interpretations in the past.
These guidelines are to be used with RFC 1543, "Instructions to RFC
Authors."
This version of the document is a draft. It is intended to generate
further discussion and addition by the STDGUIDE working group. Please send
comments to stdguide at midnight.com.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-stdguide-ops-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-stdguide-ops-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-stdguide-ops-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970528170314.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-stdguide-ops-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-stdguide-ops-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970528170314.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09525; 29 May 97 9:56 EDT
Received: from ietf.ietf.org by ietf.org id aa08766; 29 May 97 9:44 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
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-mib-07.txt
Date: Thu, 29 May 1997 09:44:09 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705290944.aa08766 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.
Note: This revision reflects comments received during the last call period.
Title : RSVP Management Information Base
Author(s) : F. Baker, J. Krawczyk
Filename : draft-ietf-rsvp-mib-07.txt
Pages : 80
Date : 05/28/1997
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing the Resource Reservation
Protocol (RSVP) within the interface attributes defined in the Integrated
Services Model. Thus, the Integrated Services MIB is directly relevant to
and cross-referenced by this MIB. Comments should be made to the RSVP
Working Group, rsvp at isi.edu.
This memo does not, in its draft form, specify a standard for
the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rsvp-mib-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-mib-07.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rsvp-mib-07.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970528143624.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rsvp-mib-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-mib-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970528143624.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09518; 29 May 97 9:56 EDT
Received: from ietf.ietf.org by ietf.org id aa08733; 29 May 97 9:44 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: tn3270e at list.nih.gov
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-tn3270e-ver2-enhance-00.txt
Date: Thu, 29 May 1997 09:43:53 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705290944.aa08733 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 Telnet TN3270 Enhancements
Working Group of the IETF.
Title : TN3270 Enhancements
Author(s) : B. Kelly
Filename : draft-ietf-tn3270e-ver2-enhance-00.txt
Pages : 34
Date : 05/28/1997
This document describes a protocol that more fully supports 3270 devices
than do the existing tn3270 practices. Specifically, it defines a method
of emulating both the terminal and printer members of the 3270 family of
devices via Telnet; it provides for the ability of a Telnet client to
request that it be assigned a specific device-name (also referred to as "LU
name" or "network name"); finally, it adds support for a variety of
functions such as the ATTN key, the SYSREQ key, and SNA response handling.
This protocol is negotiated under the TN3270E Telnet Option, and is
unrelated to the Telnet 3270 Regime Option as defined in RFC 1041[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-tn3270e-ver2-enhance-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-tn3270e-ver2-enhance-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-tn3270e-ver2-enhance-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970528141724.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-tn3270e-ver2-enhance-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tn3270e-ver2-enhance-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970528141724.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09516; 29 May 97 9:56 EDT
Received: from ietf.ietf.org by ietf.org id aa08631; 29 May 97 9:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: dhcp-v4 at bucknell.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dhc-v6exts-06.txt
Date: Thu, 29 May 1997 09:43:42 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705290943.aa08631 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Dynamic Host Configuration
Working Group of the IETF.
Title : Extensions for DHCPv6
Author(s) : C. Perkins
Filename : draft-ietf-dhc-v6exts-06.txt
Pages : 25
Date : 05/28/1997
The Dynamic Host Configuration Protocol for IPv6 [4] (DHCPv6) provides a
framework for passing configuration information to hosts on a TCP/IP
network. Configuration parameters and other control information are
carried in typed data items that are stored in the "extensions" field of
the DHCPv6 message. The data items themselves are also called
"extensions."
This document specifies the current set of DHCPv6 extensions. This
document will be periodically updated as new extensions are defined. Each
superseding document will include the entire current list of valid
extensions.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-v6exts-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-v6exts-06.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dhc-v6exts-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970528114809.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-v6exts-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-v6exts-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970528114809.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09522; 29 May 97 9:56 EDT
Received: from ietf.ietf.org by ietf.org id aa08710; 29 May 97 9:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: idmr at cs.ucl.ac.uk
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-idmr-pim-dm-spec-05.txt
Date: Thu, 29 May 1997 09:43:57 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705290943.aa08710 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Inter-Domain Multicast
Routing Working Group of the IETF.
Title : Protocol Independent Multicast Version 2,
Dense Mode Specification
Author(s) : S. Deering, D. Estrin, D. Farinacci,
V. Jacobson, A. Helmy, L. Wei
Filename : draft-ietf-idmr-pim-dm-spec-05.txt
Pages : 12
Date : 05/28/1997
This specification defines a multicast routing algorithm for multicast
groups that are densely distributed across an internet. The protocol is
unicast routing protocol independent. It is based on the PIM sparse-mode
[PIMSM] and employs the same packet formats. This protocol is called
dense-mode PIM. The foundation of this design was largely built on
[Deering91].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-idmr-pim-dm-spec-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-pim-dm-spec-05.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-idmr-pim-dm-spec-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970528142734.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-idmr-pim-dm-spec-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idmr-pim-dm-spec-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970528142734.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09527; 29 May 97 9:56 EDT
Received: from ietf.ietf.org by ietf.org id aa08669; 29 May 97 9:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-davie-mpls-rsvp-00.txt
Date: Thu, 29 May 1997 09:43:47 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705290943.aa08669 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Use of Label Switching With RSVP
Author(s) : B. Davie, Y. Rekhter, E. Rosen
Filename : draft-davie-mpls-rsvp-00.txt
Pages : 11
Date : 05/28/1997
Multiprotocol Label Switching (MPLS) allows labels to be bound
to various granularities of forwarding information, including
application flows. In this document we present a specification
for allocating and binding labels to RSVP flows, and distributing
the appropriate binding information using RSVP messages.
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-davie-mpls-rsvp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-davie-mpls-rsvp-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-davie-mpls-rsvp-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970528134730.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-davie-mpls-rsvp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-davie-mpls-rsvp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970528134730.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09530; 29 May 97 9:56 EDT
Received: from ietf.ietf.org by ietf.org id aa08731; 29 May 97 9:44 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
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-15.txt, .ps
Date: Thu, 29 May 1997 09:44:03 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705290944.aa08731 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.
Note: This revision reflects comments received during the last call period.
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-15.txt, .ps
Pages : 110
Date : 05/28/1997
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-15.txt".
Or
"get draft-ietf-rsvp-spec-15.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-spec-15.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rsvp-spec-15.txt".
Or
"FILE /internet-drafts/draft-ietf-rsvp-spec-15.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.
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: <19970528143340.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rsvp-spec-15.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-spec-15.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970528143340.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09515; 29 May 97 9:56 EDT
Received: from ietf.ietf.org by ietf.org id aa08651; 29 May 97 9:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: dhcp-v4 at bucknell.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dhc-dhcpv6-10.txt
Date: Thu, 29 May 1997 09:43:45 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705290943.aa08651 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Dynamic Host Configuration
Working Group of the IETF.
Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Author(s) : J. Bound, C. Perkins
Filename : draft-ietf-dhc-dhcpv6-10.txt
Pages : 36
Date : 05/28/1997
The Dynamic Host Configuration Protocol (DHCPv6) provides a framework for
passing configuration information, via extensions, to IPv6 nodes. It
offers the capability of automatic allocation of reusable network addresses
and additional configuration flexibility. This protocol should be
considered a stateful counterpart to the IPv6 Stateless Address
Autoconfiguration protocol specification.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-dhcpv6-10.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-dhcpv6-10.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dhc-dhcpv6-10.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970528115119.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-dhcpv6-10.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-dhcpv6-10.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970528115119.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09514; 29 May 97 9:56 EDT
Received: from ietf.ietf.org by ietf.org id aa08784; 29 May 97 9:44 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
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-md5-03.txt
Date: Thu, 29 May 1997 09:44:13 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705290944.aa08784 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.
Note: This revision reflects comments received during the last call period.
Title : RSVP Cryptographic Authentication
Author(s) : F. Baker
Filename : draft-ietf-rsvp-md5-03.txt
Pages : 15
Date : 05/28/1997
This document describes the format and use of RSVP's INTEGRITY object to
provide hop-by-hop integrity and authentication of RSVP messages.
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-md5-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-md5-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rsvp-md5-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
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: <19970528143905.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rsvp-md5-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-md5-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970528143905.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09524; 29 May 97 9:56 EDT
Received: from ietf.ietf.org by ietf.org id aa08823; 29 May 97 9:44 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-wessels-icp-v2-03.txt
Date: Thu, 29 May 1997 09:44:23 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9705290944.aa08823 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Internet Cache Protocol (ICP), version 2
Author(s) : D. Wessels, K. Claffy
Filename : draft-wessels-icp-v2-03.txt
Pages : 9
Date : 05/28/1997
This draft document describes version 2 of the Internet Cache Protocol
(ICPv2) as currently implemented in two World-Wide Web proxy cache
packages[3,5]. ICP is a lightweight message format used for communicating
among Web caches. ICP is used to exchange hints about the existence of
URLs in neighbor caches. Caches exchange ICP queries and replies to gather
information to use in selecting the most appropriate location from which to
retrieve an object.
This document describes only the format and fields of ICP messages.
A companion document (RFCXXXX, <draft-wessels-icp-v2-appl-01.txt>)
describes the application of ICP to Web caches. Several independent
caching implementations now use ICP, and we consider it important to
codify the existing practical uses of ICP for those trying to implement,
deploy, and extend its use for their own purposes.
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-wessels-icp-v2-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-wessels-icp-v2-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-wessels-icp-v2-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970528171618.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-wessels-icp-v2-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-wessels-icp-v2-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970528171618.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13460; 29 May 97 11:22 EDT
Received: from venera.isi.edu by ietf.org id aa13162; 29 May 97 11:15 EDT
Received: from relay6.UU.NET by venera.isi.edu (5.65c/5.61+local-28)
id <AA28811>; Thu, 29 May 1997 08:11:55 -0700
Received: from rodan.UU.NET by relay6.UU.NET with ESMTP
(peer crosschecked as: rodan.UU.NET [153.39.130.10])
id QQcrqi14734; Thu, 29 May 1997 11:12:03 -0400 (EDT)
Received: from sayshell.UU.NET by rodan.UU.NET with SMTP
(peer crosschecked as: sayshell.UU.NET [153.39.251.30])
id QQcrqi19711; Thu, 29 May 1997 11:11:22 -0400 (EDT)
Message-Id: <QQcrqi19711.199705291511 at rodan.UU.NET>
To: me at usa.net
Cc: ietf at isi.edu
Sender:ietf-request at ietf.org
From: "Louis A. Mamakos" <louie at uu.net>
Subject: Re: the case of the vanishing e-mail
References: <199705290349.WAA20761 at kcnet.com>
In-Reply-To: Your message of "Wed, 28 May 1997 22:49:52 -0000."
<199705290349.WAA20761 at kcnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 29 May 1997 11:11:17 -0400
X-Orig-Sender: louie at uu.net
Source-Info: From (or Sender) name not authenticated.
Contrary to popular belief, the IETF mailing list is not a help desk. Why
not have your service provider investigate the problem, or if you are
the service provider, contact the other party directly?
Louis Mamakos
(Others: please spare us the random conference announcements, too.)
Received: from ietf.org by ietf.org id aa27745; 29 May 97 16:16 EDT
Received: from ietf.ietf.org by ietf.org id aa27485; 29 May 97 16:09 EDT
To: IETF-Announce: ;
Subject: Unedited Minutes from Memphis IETF Meeting
Sender:ietf-announce-request at ietf.org
From: IETF Proceedings <minutes at ietf.org>
Date: Thu, 29 May 1997 16:09:25 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9705291609.aa27485 at ietf.org>
The unedited minutes from the Memphis IETF meeting can now be accessed
via the Web at from the IETF Online Proceedings Web Page at:
http://www.ietf/org/proceedings/directory.html
Received: from cnri by ietf.org id aa02556; 29 May 97 17:06 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11734;
29 May 97 17:05 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <TAA03299 at pad-thai.cam.ov.com>; Thu, 29 May 1997 19:05:22 GMT
Message-Id: <199705291905.PAA10819 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: RFC2078bis: DRAFT 2 of actions and issues
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 29 May 1997 15:05:13 -0400
From: John Linn <linn at cam.ov.com>
Precedence: bulk
Revised 2078bis working Draft 2 (D2), as of 29 May 1997
Here's a revision of the 2078bis actions and issues list, intended to
be responsive to discussion. Changed items have been annotated. As
usual, review and comment solicited; I propose that we consider the
time between now and Friday, 6 June as a review and discussion period
in order to be able to issue a final revision thereafter.
I: ACTIONS ASSUMED AGAINST RFC-2078:
GENERAL:
Need to align RFC-2078bis to match C bindings by deleting
gss_release_oid(), gss_oid_to_str() and gss_str_to_oid() and removing
references to them.
State that zero-length tokens are never returned by GSS routines for
transfer to a peer, though it is possible for a zero-length object to
be passed by a caller into gss_wrap(), in which case the corresponding
peer calling gss_unwrap() will receive an empty object. Similarly,
it's presumably possible to call gss_getmic() on an empty object,
yielding a MIC which gss_verifymic() would successfully verify against
the context if it were also passed a zero-length object.
Align RFC-2078bis to match C bindings' text which, within descriptions
of routines returning dynamic data, discusses the circumstances under
which objects are returned and identifies which routine should be used
to free that data.
Add explicit statement that "release" routines may be omitted from
GSS-API implementations in environments where they are not required.
Clarify byte ordering in exported name object (sec. 3.2) to a
statement of big-endian / IP network byte order / most significant
byte first. Desirably, include concrete octet-level description and
example for exported name object.
For gss_delete_sec_context(), add explicit statement that routine can
support and should be used for, deletion of "half-built" security
contexts resulting from an incomplete sequence of context
establishment calls following an initial successful call to
gss_init_sec_context() or gss_accept_sec_context(), as well as for
deletion of fully-established contexts.
Add GSS_S_BAD_MIC as an alias for GSS_S_BAD_SIG.
Align gss_export_sec_context() discussion with cbind-04, by stating
(1) specifically that the context is deactivated from the viewpoint of
the calling process upon a successful export, and (2) regarding
behavior in case of errors in the course of a context export
operation.
For gss_import_sec_context(), clarify that the imported context is
usable for all per-message operations and may be deleted or exported
by its importer. The inability to receive delegated credentials
through gss_import_sec_context() precludes establishment of new
contexts based on information delegated to the importer's end system
within the context which is being imported, unless those delegated
credentials are obtained through separate routines (e.g., XGSS-API
calls) outside the GSS-V2 definition.
For gss_verify_mic(), reword reference to "confidentiality fields of
output qop_state", since no such fields or structure are globally
defined in a cross-mechanism fashion.
Fix formatting of comments in argument descriptions: should
consistently be set off with " -- ", not single hyphens.
[D2: description revised] Reflect within 2078bis those discussions
from cbind-05 which have semantic implications and
environment-independent scope. As specific examples, adapt cbind-04's
Secs. 6.1, Delegation, and 6.6, Inter-Process Context Transfer, as
basis for new and corresponding subsections of Section 1.2, providing
clarifying material alongside RFC-2078 discussions of other
context-level features.
Adapt intro text to cbind-04's Sec. 6 (Additional Controls), providing
clarifying material concerning support for optional services, into
Sec. 1.2.
[D2: moved from issues to actions] Re gss_display_status(), state that
some language bindings may employ an iterative approach in order
to emit status components, but do not describe or define a specific
approach.
[D2: moved from issues to actions] Per gss_init_sec_context() and
gss_accept_sec_context(), allow (but do not require) emitted mech_type
return to be valid before GSS_S_COMPLETE, and for the value to change
upon successive calls for the negotiating mechanism case.
CREDENTIAL-RELATED:
Re gss_release_cred() called with GSS_C_NO_CREDENTIAL, align with
cbind-04 by stating that this action, if requested, will complete
successfully but will have no other effect.
State that gss_inquire_cred() and gss_inquire_cred_by_mech() with
GSS_C_NO_CREDENTIAL queries default initiator creds.
In gss_add_cred(), align with C bindings description of behavior
when addition of elements to default credential is requested via
GSS_C_NO_CREDENTIAL input_cred_handle.
For gss_acquire_cred() and gss_add_cred(), adopt text from cbind-04's
description of gss_acquire_cred concerning behavior when GSS_C_NO_NAME
provided for desired_name. [ISSUE FOR CBIND: I believe that this
text (or suitable variant thereof) should appear under gss_add_cred()
as well as gss_acquire_cred(); as of cbind-04, there's no commentary
about gss_add_cred()'s behavior with this case.]
For gss_acquire_cred() and gss_add_cred(), add
GSS_S_CREDENTIALS_EXPIRED as returnable major_status.
Deprecate GSS_S_CREDENTIALS_EXPIRED returns from per-message calls,
and from context-level calls other than gss_init_sec_context() and
gss_accept_sec_context().
For gss_acquire_cred(), add GSS_S_NO_CRED as returnable major_status.
Upgrade recommendation in Section 1.1.1.3, concerning behavior for
default credential resolution, to status of requirement for initiator
credentials. GSS_S_NO_CRED to be returned if credentials can't
be resolved.
[D2: moved from issues to actions] For both gss_acquire_cred() and
gss_add_cred(), describe GSS_S_NO_CRED as the appropriate error to
return on temporary, user-fixable credential unavailability
conditions.
NAME-RELATED:
Align description of gss_inquire_mechs_for_name() with C bindings.
Remove GSS_S_BAD_NAMETYPE as return value from gss_duplicate_name(),
gss_display_name(). For gss_compare_name(), constrain description of
GSS_S_BAD_NAMETYPE return as being applicable only to attempted
comparisons between incomparable name types.
For gss_import_name() with GSS_C_NO_OID input_name_type, adopt
cbind statement that a mechanism-specific default printable syntax
for the associated name is used and state that GSS-V2 mechanism
specifications shall define the corresponding processing to
be performed by their mechanisms.
In gss_canonicalize_name(), include text similar to that included
for gss_duplicate_name() about the fact that the name is duplicated
and then the duplicate is reduced to the MN without impact on the
already existing input_name.
Per Sec. 4.1, change reference to use of DNS lookup as means for name
canonicalization from definitional to example.
Adapt text from 2 paragraphs in cbind-04, p. 16, regarding use and
semantics of name comparisons with exported name objects, into
Sec. 1.1.5 (Naming).
[D2: addition] Re GSS_Canonicalize_name(), state that negotiated
mechanisms, as well as the default mechanism, are not acceptable
mech_types to be specified for this operation.
[D2: addition] Remove references to "uid_t" from high-level
specification, replacing with more generic wording and deferring
reference to "uid_t" to C bindings.
[D2: addition] In name types section, add references for GSS_C_NO_OID
and the anonymous nametype.
[D2: addition] Re GSS_C_NT_USER_NAME, replace statement that "Its
interpretation is OS-specific" with "Its syntax and interpretation
may be OS-specific".
[D2: addition] Re gss_display_name(), state that the GSS_C_NO_OID name
type is to be returned only when the corresponding internal name was
created through import with GSS_C_NO_OID, and that it is also
acceptable for mechanisms to normalize names imported with
GSS_C_NO_OID into other supported types and therefore display them
with types other than GSS_C_NO_OID.
[D2: addition] Recommend to GSS-V2 mechanism designers that host-based
service name type be supported in the interests of portability, while
still deferring any actual requirement statement for a particular
mechanism to that mechanism's specification.
NEGOTIATION-RELATED:
Incorporate a general statement about the distinction between
negotiating and non-negotiating mechanisms, and the properties of
each. State that applications requesting a specific mechanism shall
not receive another mechanism unless the definition of the mechanism
specified indicates that it is a negotiating mechanism. (See also
Martin Rex 19 Mar 97 msg)
II: RESIDUAL ISSUES, DISTILLED:
GENERAL ISSUES:
[D2: new issue] Can we constrain the circumstances under which
supplementary info bits may be set along with a non-zero routine
error, and what, if any, constraints can be imposed on the set of
supplementary info bits returnable from a single call? [PROPOSED
ACTION: Discussion needed.]
[D2: new issue] Do we intend to include any facility, in the interests
of support for negotiating mechanisms, which enables callers of
gss_init_sec_context() to indicate whether or not they wish and/or
require per-message confidentiality and integrity services? [PROPOSED
ACTION: Resolution pending on convergence of separate negotiated
mechanism discussion.]
CREDENTIAL-RELATED ISSUES:
[D2: proposed action changed] Upgrade recommendation in Section
1.1.1.3, concerning behavior for default credential resolution, to
status of requirement for acceptor credentials? GSS_S_NO_CRED would be
returned if credentials can't be resolved. [PROPOSED ACTION: No
apparent consensus for upgrade of recommendation, so no action
planned.]
[D2: proposed action changed] For gss_acquire_cred() and
gss_add_cred(), align with cbind-04 statement of likely non-support
for INITIATE and BOTH credentials if a non-empty name is specified?
Martin Rex objects (28 Apr 97, reiterating earlier comment) to
cbind-04 statement, recommends requiring same scope of function as
gss_init_sec_context() and gss_accept_sec_context() provide with
GSS_C_NO_CREDENTIAL. [PROPOSED ACTION: Adopt the statement from
cbind-04, but specifically include specification of the name which
would result from inquiring against the default credential, as well as
an empty name, within the set for which support is expected. Should
also reflect in C bindings.]
Transfer of delegated credentials via gss_export_sec_context(); access
to delegated credentials by gss_import_sec_context() caller? [PROPOSED
ACTION: This issue has been recognized for some time; assumed plan is
to defer beyond GSS-V2.]
NAME-RELATED ISSUES:
[D2: new issue] Include strong recommendation to designers of
mechanisms having de facto native nametypes that GSS_C_NO_OID be
supported in those mechanisms? [PROPOSED ACTION: Accept concept, but
need better definition of the class of mechanisms to which it
applies.]
[D2: new issue] State that requirements for support or non-support
of particular name types are not specified within 2078bis but are
instead deferred to mechanism specifications? [PROPOSED ACTION: Accept.]
[D2: proposed action changed] Should UID name forms be indicated as
optional and possibly environment-dependent, as they had been in
RFC-1964? Should their descriptions be revised, and, if so, how?
[PROPOSED ACTION: State as environment-dependent; per earlier proposed
action, name types need not be individually cited as optional. Leave
descriptions as is.]
[D2: proposed action changed] Should user name form be indicated as
optional and possibly environment-dependent, as it had been in
RFC-1964? Should its description be revised, and, if so, how?
[PROPOSED ACTION: State as environment-dependent; per earlier proposed
action, name types need not be individually cited as optional. Leave
description as is.]
[D2: issue revised] Per late March-early April discussion, is it
feasible or appropriate to define and adopt a generic "distributed
user name" type? Requestor (Martin Rex) withdrew proposal contingent
on (a) describing support for GSS_C_NO_OID with gss_import_name() as
mechanism-specific (vs. implementation specific) and (b) strongly
recommending to designers of mechanisms having de facto native
nametypes that GSS_C_NO_OID be supported in those
mechanisms. [PROPOSED ACTION: Add no new type.]
Allow GSS_S_NAME_NOT_MN as optional return value from
gss_compare_name(), per 2 Apr 97 mail? [PROPOSED ACTION: Do not
incorporate: return of this GSS-V2 major_status code could confuse
GSS-V1 callers.]
[D2: new issue] If negotiated mechanism mech_type passed to
GSS_Canonicalize_name(), should GSS_S_BAD_MECH or GSS_S_FAILURE be
returned, recognizing that the implementation does support the
negotiated mechanism's mech type even though it's inappropriate for
the specific operation requested? [PROPOSED ACTION: I propose that we
should recommend GSS_S_BAD_MECH for this case; in
GSS_Init_sec_context(), e.g., we already have precedent for use of
this code in conjunction with a mechanism which is supported by the
implementation, but which can't be applied for a particular
operation.]
NEGOTIATION-RELATED ISSUES:
Attempt any treatment of the "mechanism family" concept at this time?
List discussion on 19 March proposed the concept of mechanism families
with multiple individual OIDs, each of which can support the same name
types. See also Martin Rex questions re gss_canonicalize_name(), 3
Apr 97, and follow-up discussion. [PROPOSED ACTION: Defer beyond
GSS-V2.]
ISSUES RE STATUS VALUES AND OPERATIONAL BEHAVIOR:
Can we tighten any requirements statements per Martin Rex's 14 Mar
query about required/optional/etc, and follow-up correspondence?
[PROPOSED ACTION: Many, but not all, of the points raised in this
message appear in this listing as separate actions or issues, and some
of the points raised may have answers which are mechanism-specific,
and comprehensive follow-up about requirements levels was not
apparent. I propose, therefore, not to make text changes in response
to the cited message unless further discussion ensues; additional
issues or actions can be opened subsequently as dictated by
discussion.]
Page 22 of cbind-04, re GSS_S_DUPLICATE_TOKEN, states that the status
may be returned for some cases even if replay detection isn't being
provided; this diverges from RFC-2078. John Linn and Ted Ts'o suggest
that cbind should align with GSS-V1 and RFC-2078, precluding this
prospect. [PROPOSED ACTION: No change to RFC-2078, anticipating
possible alignment by C bindings.]
--jl
Received: from ietf.org by ietf.org id aa15273; 30 May 97 16:48 EDT
Received: from proxy4.ba.best.com by ietf.org id aa21614; 30 May 97 15:06 EDT
Received: from [205.149.180.135] (boo.vip.best.com [205.149.180.135]) by proxy4.ba.best.com (8.8.5/8.8.3) with ESMTP id MAA22084 for <ietf at ietf.org>; Fri, 30 May 1997 12:00:39 -0700 (PDT)
X-Sender: boo at shell5.ba.best.com
Message-Id: <v03102801afb4d0d867f8 at [205.149.180.135]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Quote: I wasn't innocent till I got older. --WIK
X-Calibur: Signifying that I, Arthur, was to become King of the Britons
X-Mailer: Eudora Pro 3.1 for MacOS
Date: Fri, 30 May 1997 11:58:40 -0700
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Walter Ian Kaye <walter at natural-innovations.com>
Subject: Forged spam headers
Source-Info: From (or Sender) name not authenticated.
Why can't forging be cut off at the beginning of its journey?
I've excerpted portions of spam I just received, showing the totally evil
things their software does.
--- begin forwarded text
Received: from proxy2.ba.best.com (root at proxy2.ba.best.com
[206.184.139.13]) by shell5.ba.best.com (8.8.5/8.7.3) with ESMTP id
=46AA17152 for <boo at shell5.ba.best.com>; Fri, 30 May 1997 05:51:46 -0700 (PD=
T)
=46rom: 63414679 at calypso.com
Received: from dns1.intermex.com.mx (dns1.intermex.com.mx [200.34.131.2])
by proxy2.ba.best.com (8.8.5/8.8.3) with SMTP id FAA22727 for
<boo at best.com>; Fri, 30 May 1997 05:51:24 -0700 (PDT)
Received: from dns1.intermex.com.mx by dns1.intermex.com.mx via SMTP
(940816.SGI.8.6.9/940406.SGI.AUTO)
id HAA14863; Fri, 30 May 1997 07:41:11 -0500
Received: from mail.J82e8d2.net by mail.J82e8d2.net (8.8.5/8.6.5) with SMTP
id GAA05233 for <U at Yourdomain.com>; Fri, 30 May 1997 05:54:41 -0600 (EST)
Date: Fri, 30 May 97 05:54:41 EST
To: U at Yourdomain.com
Subject: Stealth Mass Mailer----The Ultimate Online Marketing Tool
Message-ID: <742590688053BBD2344 at XdX24d9067u5.com>
Reply-To: do-not at no-reply.com
X-PMFLAGS: 34078848 0
Comments: Authenticated sender is <mailhost33.X0Xkkd.net>
X-UIDL: 53309006788311577563790876653250
[snip]
Connect to multiple mail servers, make multiple connections to a
single server or any combination of the two ( All Simultaneously )
with one single dial-up connection.
After your message is sent out by the selected mail server(s), you can
then have it relayed through another mail server or through multiple
mail servers, in any server order you choose.
[snip]
NOTE: You only need one dial-up connection, and you can send
email out through over 4,000 service providers accounts FREE!
Here are just a few features the STEALTH MASS MAILER
offers to you...
+Forge the Header - Message ID - ISP's will Spin their wheels.
+Add's a Bogus Authenticated Sender to the Header.
+Add's a complete bogus Received From / Received By line with
real time / date stamp and recipient to the Header.
+Does NOT require a valid POP Account be entered in order to
send your mailings.
[snip]
**SPECIAL BONUS #1: STOP Losing ISP Dial Up Accounts!
[snip]
Complete instructions on "how to keep your dial up account from
showing up in the header", plus everything you will need to get started
doing this.
IMPORTANT NOTICE!
We will initially only be offering 100 copies of the program for sale, First
come / First Served basis only. We are doing this because of the extreme
power that this program offers the potential for trouble. After the first
100 copies are sold, there will be a 30 day waiting period, after which
time we will decide whether or not to continue selling the program.
[snip]
If you have any questions don=EDt hesitate to call us at:
1-504-936-3573
[snip]
Please send all order forms and check, money order or credit card
authorization to:
Gulf Coast Marketing
8867 Highland Rd. Suite 112
Baton Rouge, LA 70808
OR:
=46ax Your Credit Card Authorization to:
504-757-9988
[snip]
--- end forwarded text
__________________________________________________________________________
Walter Ian Kaye <boo_at_best*com> Programmer - Excel, AppleScript,
Mountain View, CA ProTERM, FoxPro, HTML
http://www.natural-innovations.com/ Musician - Guitarist, Songwriter
Received: from ietf.org by ietf.org id aa27883; 30 May 97 17:10 EDT
Received: from cnri by ietf.org id aa27417; 30 May 97 17:08 EDT
Received: from cbgw1.lucent.com by CNRI.Reston.VA.US id aa11812;
30 May 97 17:08 EDT
Received: from hoserve.ho.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2)
id QAA25562; Fri, 30 May 1997 16:56:07 -0400
Received: by hoserve.ho.lucent.com (4.1/EMS-L SunOS)
id AA13499; Fri, 30 May 97 16:45:41 EDT
Sender:ietf-request at ietf.org
From: rameshn at lucent.com
Received: from hopaw33 (hopaw33.ho.lucent.com) by hoserve.ho.lucent.com (4.1/EMS-L SunOS)
id AA13411; Fri, 30 May 97 16:44:28 EDT
Received: by hopaw33 (4.1/EMS-L SunOS)
id AA00387; Fri, 30 May 97 16:51:02 EDT
Date: Fri, 30 May 97 16:51:02 EDT
Original-From: ramesh at hoserve.ho.lucent.com
Message-Id: <9705302051.AA00387 at hopaw33>
To: ietf at CNRI.Reston.VA.US
Subject: IEEE INFOCOM'98: Tutorials and Panels
Source-Info: From (or Sender) name not authenticated.
Dear Colleagues,
Please find attached a list of potential topics for tutorials
and panels to be offered at IEEE INFOCOM'98. In order to more accurately
reflect general interests of the community at large, we are
requesting you to provide us with feedback on this list of topics.
We ask that your feedback be in the form of a rank ordering
of the topic list based on your interests. In addition, you may
provide additional topics of interest as write-in candidates.
As an example:
Full-day tutorials: 4,3,6e,"favorite topic",1.
Panels: 2,3,1,4.
Please DO NOT reply to this mail, but rather send your
feedback on tutorials to the tutorial co-chairs:
Arvind Krishna and/or Catherine Rosenberg
e-mails: krishna at watson.ibm.com C.Rosenberg at nortel.co.uk
and feedback on panels to the panel co-chairs:
David Tipper and/or Vittorio Trecordi
e-mails: tipper at lis.pitt.edu vit at ercole.cefriel.it
Looking to your responses and thanks in advance for your
attention and time.
As a reminder, the call for papers deadline for INFOCOM'98
is fast approaching (July 15). For more information, please
visit one of our web sites:
USA: http://www.comsoc.org/~infocom98
Europe: http://www.cs.ucl.ac.uk/research/infocom98
Asia/Pacific: http://www.iss.nus.sg/INFOCOM
The list of panel and tutorial topics and a feedback form is
available at the USA web site (others shortly) and you may choose to
send your feedback via the web if it is more convenient.
Regards,
Ramesh.
TUTORIALS
---------
Full-day tutorials
__________________
1. IP v6
This tutorial will provide an in depth review of the IPv6 protocol,
its packets formats, and functionality. Changes from IPv4 will be
highlighted, and issues related to migration from IPv4 to IPv6 will
also be covered.
2. Transport protocols in the Internet
incl. TCP, RTP (& RTCP), rate based TCP, RSVP & TCP, etc.
This tutorial covers Internet Transport protocols, their operation,
performance, functionality, and recent enhancements. Issues related
with interactions with other protocols, e.g., RTP and RSVP, will
also be addressed.
3. Broadband services over Satellite
This tutorial reports on current proposals for deploying a broadband
satellite based communication infrastructure. The underlying technologies
as well as technical challenges will be reviewed, and an assessment of
the current status of such systems will be provided.
4. Security (IP and ATM)
With the increased penetration of distributed (network) computing and
the use of networks to support critical business applications, (network)
security has become a key concern to most users. This tutorial will review
major security issues and technologies, starting with basic cryptographic
primitives for authentication, encryption, and key management, and including
their use in IP and ATM standards to provide various security capabilities.
Existing technologies such as firewall will also be covered.
5. New Access technologies
This tutorial will cover the many recent progress in access technologies.
It will cover basic technologies underlying new modem offerings, including
56kbps modems, xDLS modems, and cable modems. Issues related to the
requirements they impose on existing infrastructure will also be addressed.
6. Others
a) Scalable Routing & IP switching
b) Optical networking
c) QoS support within the network
d) MULTIMEDIA Concept, Technical Challenges, and Implementation
e) Traffic Characterization
f) ATM standards activity
Half-day Tutorials
__________________
1. Pricing for broadband networks
As new services are being offered, it becomes important
to determine their cost to the network and also how this
cost is to apportioned to users. The latter is of particular
interest in the case of multicast connections. This tutorial
will review existing models for pricing new services as
well as results on the efficiency of pricing in controlling
users behaviors.
2. Mobility topic (only one of those below)
a) UMTS or Internet mobility
b) Next generation wireless networks
c) Mobility support in the Internet
3. Multicast
Multicast is becoming an increasingly important service for many
users, but imposes many specific requirements on the infrastructure
and end-users. This tutorial will review existing protocols and
technology in support of multicast, and will illustrate the use
of multicast capabilities by several applications. Unique requirements
of multicast, e.g., reliability, will be highlighted and existing
solutions will be reviewed.
4. ATM Block Transfer
This tutorial will focus on providing an in depth treatment of the
ABT service defined in the ITU, and identify scenarios for which it
provides a unique solution. Implementation related requirements
and existing technology in support of ABT will also be reviewed.
PANELS
------
1. Active Networks - Hype or Next Big Thing?
Active network research programs have begun with the aim
of having network components (e.g. switches) perform
customized computations
on the packets/applications flowing through them.
This panel focuses on the goals and feasibility of such an approach
and possible alternatives
2. Networking: State of the Art Report and Future Directions
Presentation from three leading research directors
one each from: Europe, Asia/Pacific, North America
Short presentation 20 minutes each - followed by 10 minute
panel discussion - followed by question/answer session.
3. Broadband Wireless Systems
Discuss services to be provided, possible architectures
and support for mobility.
Panelist from the competing proposed architecture groups
4. Can/Should Public Communication Networks Be Secure?
Discuss the technical and political aspects of
providing authentication and privacy in public communication networks
such at the Internet and Cellular phones.
Technical issues in providing widespread security
include network management, scalability,
cryptography and protection of computing/networking resources .
Regulatory and political issues include governments rite to tap
conversations, business needs to monitor employee activity and
``Communication Decency Act''
5. Evolution of Internet and Telecommunications
panelists from the telcos, ISPs, core Internet
Discuss services(data, phone,etc.), features, growth and reliability
of Internet and PSTN - who will be the service providers of
tommorrow
Received: from ietf.org by ietf.org id aa25303; 31 May 97 1:42 EDT
Received: from black-ice.cc.vt.edu by ietf.org id aa25119; 31 May 97 1:34 EDT
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.6.Beta3/8.8.6.Beta3) with ESMTP id BAA19922;
Sat, 31 May 1997 01:30:59 -0400
Message-Id: <199705310530.BAA19922 at black-ice.cc.vt.edu>
To: Walter Ian Kaye <walter at natural-innovations.com>
Cc: ietf at ietf.org
Subject: Re: Forged spam headers
In-Reply-To: Your message of "Fri, 30 May 1997 11:58:40 PDT."
<v03102801afb4d0d867f8 at [205.149.180.135]>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <v03102801afb4d0d867f8 at [205.149.180.135]>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1763417210P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Sat, 31 May 1997 01:30:58 -0400
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_1763417210P
Content-Type: text/plain; charset=us-ascii
On Fri, 30 May 1997 11:58:40 PDT, you said:
> Why can't forging be cut off at the beginning of its journey?
> I've excerpted portions of spam I just received, showing the totally evil
> things their software does.
It can. See http://www.sendmail.org/antispam.html for a Sendmail solution,
or http://spam.abuse.net/spam/tools/ for a collection of many tools for
many systems.
The problem is that all the *clued* Sendmail administrators will install
anti-relay filters in their sendmail.cf. At our campus, that will probably
cut off 200 or 300 machines from acting as spam relays.
What it *wont* do is deal with the *other* 300 machines that we don't have
administrative control over, that were last administered by a grad student
who was really more interested in crystallography, etc etc.
And let's face it - the same people who aren't clued or motivated to install
the patches are the same people who aren't clued or motivated to check their
system logs, so they will never even *know* they were just used as a spam
relay.....
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
--==_Exmh_1763417210P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBM4+3jtQBOOoptg9JAQHGGQP/V6T+o7iG8Jv65vs1iP65RaJw9hzoGM7e
/AEFwmYiJ1Eh/SKLMkFk5t3E7HSi5Bws/8udDuOc7d9SHWGL3L3HqJW0MfrYq4Rq
dQ/inOy1ytOCLudH65hcsMNsEb7Q57DqjCE1A86Cd7WgyZQ5UzqEIBTmn/6sjXhm
U9sWGtShXhE=
=EwsR
-----END PGP MESSAGE-----
--==_Exmh_1763417210P--
Received: from ietf.org by ietf.org id aa26655; 31 May 97 2:28 EDT
Received: from venera.isi.edu by ietf.org id aa26594; 31 May 97 2:27 EDT
Received: from fiu.edu by venera.isi.edu (5.65c/5.61+local-28)
id <AA26185>; Fri, 30 May 1997 23:23:39 -0700
Received: from zero-crash (fiudial43.fiu.edu [131.94.2.43])
by fiu.edu (8.8.5/8.8.5) with ESMTP id CAA21313
for <ietf at isi.edu>; Sat, 31 May 1997 02:25:42 -0400 (EDT)
Message-Id: <338FC44B.718A007B at fiu.edu>
Date: Sat, 31 May 1997 02:25:15 -0400
Sender:ietf-request at ietf.org
From: Zero Crash <arodri34 at fiu.edu>
X-Mailer: Mozilla 4.0b3 [en] (WinNT; I)
Mime-Version: 1.0
To: ietf at isi.edu
Subject: [Fwd: the case of the vanishing e-mail]
X-Priority: 3 (Normal)
Content-Type: multipart/mixed; boundary="------------62D52FA64070DDB6AA2C2E18"
Source-Info: From (or Sender) name not authenticated.
This is a multi-part message in MIME format.
--------------62D52FA64070DDB6AA2C2E18
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--------------62D52FA64070DDB6AA2C2E18
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Received: from ietf.org (ietf.org [132.151.1.19])
by fiu.edu (8.8.5/8.8.5) with SMTP id AAA17464
for <arodri34 at fiu.edu>; Thu, 29 May 1997 00:01:57 -0400 (EDT)
Received: from ietf.org by ietf.org id aa22686; 29 May 97 0:00 EDT
Received: from venera.isi.edu by ietf.org id aa22545; 28 May 97 23:57 EDT
Received: from kcnet.com by venera.isi.edu (5.65c/5.61+local-28)
id <AA16665>; Wed, 28 May 1997 20:53:10 -0700
Received: from newman (pm3x26.kcnet.com [206.102.129.91])
by kcnet.com (8.8.5/8.8.5) with SMTP id WAA20761
for <ietf at isi.edu>; Wed, 28 May 1997 22:49:53 -0500
Message-Id: <199705290349.WAA20761 at kcnet.com>
Comments: Authenticated sender is <me at pop.netaddress.com>
Sender: ietf-request at ietf.org
From: "Justin B. Newman" <me at usa.net>
To: ietf at isi.edu
Date: Wed, 28 May 1997 22:49:52 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: the case of the vanishing e-mail
Reply-To: me at usa.net
Priority: normal
X-Mailer: Pegasus Mail for Win32 (v2.52)
Source-Info: From (or Sender) name not authenticated.
Recently, I have had a complete inability to send e-mail to a
particular aol subscriber from usa.net. This spans multiple usa.net
accounts, both sending from their web interface and their SMTP host
and another SMTP host with their return address. The aol account is
known to be working as e-mails from various UNIX machines all arive
in good order. Any ideas what's going wrong? I write this remembering
some discussions about usa.net and aol doing some mail filtering....
and aol is on my mind because of Steve Case's appearance on the
National Press Club today. A well done speech and q/a session, I
might add.
I recognize that there may be a more appropriate place for this
question. If you believe there to be such, your guidance will be much
appreciated.
Thanks,
-jbn
--------------62D52FA64070DDB6AA2C2E18--
Received: from ietf.org by ietf.org id aa05474; 2 Jun 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa04962; 2 Jun 97 9:28 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
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-ctrl-load-svc-05.txt
Date: Mon, 02 Jun 1997 09:28:58 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706020928.aa04962 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.
Note: This revision reflects comments received during the last call period.
Title : Specification of the Controlled-Load Network Element
Service
Author(s) : J. Wroclawski
Filename : draft-ietf-intserv-ctrl-load-svc-05.txt
Pages : 20
Date : 05/29/1997
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-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-intserv-ctrl-load-svc-05.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-intserv-ctrl-load-svc-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970529155630.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-intserv-ctrl-load-svc-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-intserv-ctrl-load-svc-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970529155630.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05467; 2 Jun 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa04982; 2 Jun 97 9:29 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
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-sig-uni4.0-04.txt
Date: Mon, 02 Jun 1997 09:29:06 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706020929.aa04982 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 : ATM Signalling Support for IP over ATM -
UNI Signalling 4.0 Update
Author(s) : M. Maher
Filename : draft-ietf-ion-sig-uni4.0-04.txt
Pages : 26
Date : 05/29/1997
This memo describes how to efficiently use the ATM call control signalling
procedures defined in UNI Signalling 4.0 [SIG40] to support IP over ATM
environments as described in RFC 1577 [LAUB94] and in [LUC97]. Among the
new features found in UNI Signalling 4.0 are Available Bit Rate signalling
and traffic parameter negotiation. This draft highlights the features of
UNI Signalling 4.0 that provide IP entities capabilities for requesting ATM
service in sites with SVC support, whether it is private ATM or publicly
provisioned ATM, in which case the SVC support is probably configured
inside PVPs.
This document is only relevant to IP when used as the well known
"best effort" connectionless service. In particular, this means that
this document does not pertain to IP in the presence of implemented
IP Integrated Services. The topic of IP with Integrated Services
over ATM will be handled by a different specification or set of
specifications being worked on in the ISSLL WG.
This specification is follow-on to RFC 1755, "ATM Signaling Support
for IP over ATM", which is based on UNI 3.1 signalling [UNI95].
Readers are assumed to be familiar with RFC 1755.
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-sig-uni4.0-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-sig-uni4.0-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ion-sig-uni4.0-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970529160250.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-sig-uni4.0-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-sig-uni4.0-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970529160250.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05473; 2 Jun 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa04942; 2 Jun 97 9:28 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: drums 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-drums-smtpupd-05.txt
Date: Mon, 02 Jun 1997 09:28:49 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706020928.aa04942 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 Detailed Revision/Update of
Message Standards Working Group of the IETF.
Title : Simple Mail Transfer Protocol
Author(s) : J. Klensin
Filename : draft-ietf-drums-smtpupd-05.txt
Pages : 61
Date : 05/29/1997
This document is a self-contained specification of the basic protocol for
the Internet electronic mail transport, consolidating and updating
* the original SMTP specification of RFC 821 [RFC-821],
* Domain name system requirements and implications for mail transport
from RFC 1035 [RFC-DNS] and RFC 974 [RFC974],
* the clarifications and applicability statements in
RFC 1123 [RFC-1123], and
* material drawn from the SMTP Extension mechanisms [SMTPEXT].
It is intended to replace RFC 821, RFC 974, and the mail transport
materials of RFC 1123. However, RFC 821 specifies some features that are
not in significant use in the Internet of the mid-1990s and, in appendices,
some additional transport models. Those sections are omitted in this
document in the interest of clarity and brevity; readers needing them
should refer to RFC 821.
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-drums-smtpupd-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-drums-smtpupd-05.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-drums-smtpupd-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970529104911.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-drums-smtpupd-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-drums-smtpupd-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970529104911.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05468; 2 Jun 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa04922; 2 Jun 97 9:28 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-leiba-imap-idle-02.txt
Date: Mon, 02 Jun 1997 09:28:44 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706020928.aa04922 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 : IMAP4 IDLE command
Author(s) : B. Leiba
Filename : draft-leiba-imap-idle-02.txt
Pages : 4
Date : 05/29/1997
The Internet Message Access Protocol [IMAP4] requires a client to poll the
server for changes to the selected mailbox (new mail, deletions). It's
often more desirable to have the server transmit updates to the client in
real time. This allows a user to see new mail immediately. It also helps
some real-time applications based on IMAP, which might otherwise need to
poll extremely often (such as every few seconds). (While the spec actually
does allow a server to push EXISTS responses aysynchronously, a client
can't expect this behaviour and must poll.)
This document specifies the syntax of an IDLE command, which will allow a
client to tell the server that it's ready to accept such real-time updates.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-leiba-imap-idle-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-leiba-imap-idle-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-leiba-imap-idle-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970529152013.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-leiba-imap-idle-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-leiba-imap-idle-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970529152013.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa07862; 2 Jun 97 11:17 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06924;
2 Jun 97 11:17 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <NAA29770 at pad-thai.cam.ov.com>; Mon, 2 Jun 1997 13:41:24 GMT
Message-Id: <199706021341.JAA13968 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: D.Pinkas at frcl.bull.fr
Cc: CAT-IETF WG <cat-ietf at mit.edu>, linn at cam.ov.com
Subject: Re: Snego & GSS V2
In-Reply-To: Your message of "Thu, 29 May 1997 13:18:29 PDT."
<338DE495.465A at frcl.bull.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 02 Jun 1997 09:41:08 -0400
From: John Linn <linn at cam.ov.com>
Precedence: bulk
Denis writes:
> Note : If we enrich, for backward compatibility, GSS_init_sec_context
> should be kept unchanged and thus it would make sense to have new APIs.
I agree. One question, though: on p. 7 of snego-05, it's stated that
"The context flags should be filled in from the req_flags parameter of
init_sec_context()." Is it necessarily required that the req_flags inputs
will always be copied precisely into the emitted token, or is it acceptable
for lower implementation layers within the client system to filter or
modify the client requests?
>
> I would favor two additional APIs, independent from GSS_Get_neg_mechs
> and GSS_Set_neg_mechs that would allow to specify the flags and make it
> part of GSS-API V2+ so that the functionality becomes available whether
> a precise mech is specified or the negotiation mechanism is specified.
This seems like a reasonable result, but would represent the first
post-2078 example of adding new calls to the GSS-API definition.
What do people think about taking such a step at this time?
--jl
Received: from cnri by ietf.org id aa09165; 2 Jun 97 12:47 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa08090;
2 Jun 97 12:47 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <OAA06979 at pad-thai.cam.ov.com>; Mon, 2 Jun 1997 14:50:38 GMT
Message-Id: <3.0.1.16.19970602104900.29ef9b62 at world.std.com>
X-Sender: dpj at world.std.com
X-Mailer: Windows Eudora Light Version 3.0.1 (16)
Date: Mon, 02 Jun 1997 10:49:00 -0400
To: cat-ietf at mit.edu
From: "David P. Jablon" <dpj at world.std.com>
Subject: brian at isi.edu, bcn at isi.edu, ari.medvinsky at cybersafe.com,
jtrostle at novell.com, wray at tuxedo.enet.dec.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
Here is a suggestion to modify pk-init-03.txt to
re-incorporate password-authenticated key exchange as
an option. The description below is a variation of what
was in pk-init-02.txt, and is somewhat incomplete,
meant primarily as a starting point for discussion.
It basically follows the idea of Barry Jaspan's 96 USENIX
paper, focusing on the password-authenticated Diffie-Hellman
exchanges.
.
An advantage of these methods over current (-03) options is
that there is no requirement for the user to have the
KDC's public-key, and no requirement for the user to
locally store a private key, which further simplifies key
management.
Proposed changes to pk-init-03.txt, denoted by change bars:
============================================
[...]
2. Introduction
The popularity of public key cryptography has produced a desire for
its support in Kerberos [2]. The advantages provided by public key
cryptography include simplified key management (from the Kerberos
| perspective), the ability to leverage existing and developing
| public key certification infrastructures, and removal of
| opportunities for brute-force password attack.
Public key cryptography can be integrated into Kerberos in a number
of ways. One is to to associate a key pair with each realm, which
can then be used to facilitate cross-realm authentication; this is
| the topic of another draft proposal. Other ways are to use public
| key methods in initial authentication, using certificates,
| using digital signature, or using password-authenticated
| exponential key exchange. This document is concerned
| with public-key methods in initial authentication.
One of the guiding principles in the design of PKINIT is that
changes should be as minimal as possible. As a result, the basic
mechanism of PKINIT is as follows: The user sends a request to the
KDC as before, except that if that user is to use public key
| cryptography in the initial authentication step, either his
| certificate or public key exchange data accompanies the initial
| request in the preauthentication fields.
| When a certificate accompanies the initial request,
| the KDC verifies the certificate and
issues a ticket granting ticket (TGT) as before, except that instead
of being encrypted in the user's long-term key (which is derived
| from a password), the TGT is encrypted with a randomly-generated key.
This
random key is in turn encrypted using the public key certificate
that came with the request and signed using the KDC's signature key,
and accompanies the reply, in the preauthentication fields.
| When a password-authenticated key exchange is used, the KDC uses
| the user's key exchange request data to create a mutually-derived
| password-authenticated Diffie-Hellman key. This key is once used to
| encrypt the TGT in the reply, instead of using the password-derived key.
| The reply also includes a preauthentication field containing the
| KDC's key exchange response, which the client uses to create
| the Diffie-Hellman key, and decrypt the TGT.
PKINIT also allows for users with only digital signature keys to
authenticate using those keys, and for users to store and retrieve
private keys on the KDC.
The PKINIT specification may also be used for direct peer to peer
authentication without contacting a central KDC. This application
of PKINIT is described in PKTAPP [4] and is based on concepts
introduced in [5, 6]. For direct client-to-server authentication,
the client uses PKINIT to authenticate to the end server (instead
of a central KDC), which then issues a ticket for itself. This
approach has an advantage over SSL [7] in that the server does not
need to save state (cache session keys). Furthermore, an
additional benefit is that Kerberos tickets can facilitate
delegation (see [8]).
3. Proposed Extensions
This section describes extensions to RFC 1510 for supporting the
use of public key cryptography in the initial request for a ticket
granting ticket (TGT).
In summary, the following changes to RFC 1510 are proposed:
--> Users may authenticate using either a public key pair or a
conventional (symmetric) key. If public key cryptography is
used, public key data is transported in preauthentication
data fields to help establish identity.
--> Users may store private keys on the KDC for retrieval during
Kerberos initial authentication.
| This proposal addresses three ways that users may use public key
cryptography for initial authentication. Users may present public
| key certificates, they may generate their own session key,
| signed by their digital signature key, or they may use a
| password-authenticated key exchange. In any case, the end
result is that the user obtains an ordinary TGT that may be used for
subsequent authentication, with such authentication using only
conventional cryptography.
Section 3.1 provides definitions to help specify message formats.
| Section 3.2, 3.3, and 3.4 describe the extensions for the three
| initial authentication methods.
| Section 3.5 describes a way for the user to
store and retrieve his private key on the KDC.
[...]
|3.4. Password-Authenticated Key Exchange
|
| This method uses a password-authenticated key
| exchange for the user and the KDC to jointly derive a
| one-time shared key, which is used to encrypt the TGT.
| The derived key is mutually-authenticated by knowledge of
| the password in a manner that resists network brute-force
| attack on the password. This method presumes the KDC
| has a stored a one-way-hashed password for the user.
|
| The client's request for a TGT is accompanied by
| a PA-PK-AS-DH-REQ message in a preauthentication field,
| which contains the user's ephemeral Diffie-Hellman public key.
| The reply has a PA-PK-AS-DH-REP message containing the
| KDC's ephemeral Diffie-Hellman public-key.
|
| PA-PK-AS-DH-REQ ::= SEQUENCE {
| flavor [0] INTEGER, -- FLAVOR_SPEKE_MODP, etc.
| Qa [1] SubjectPublicKeyInfo
| }
|
| The KDC uses the value of Qa in combination with
| the user's hashed-password to derive the one-time key K.
| The KDC then replies as per RFC 1510, except that the TGT in the
| reply is encrypted with K instead of the long-term password-derived
| key, and the value of Qb is appended in a preauthentication field.
|
| PA-PK-AS-DH-REP ::= SEQUENCE {
| Qb [0] SubjectPublicKeyInfo
| }
|
| The user uses Qb in combination with the hashed-password
| to derive K, and uses K to decrypt the TGT.
|
| Several flavors of the exchange are possible, using at least two
| different protocols, and a variety of Diffie-Hellman groups.
| The flavors FLAVOR_SPEKE_MODP and
| FLAVOR_DHEKE_MODP are described here.
|
|3.4.1 Simple Password-Authenticated Exponential Key Exchange
|
| When using FLAVOR_SPEKE_MODP, a "safe prime" p is used
| of the form p = 2q+1, with prime q, and the base g for the Diffie-
| Hellman exchange is computed from the hashed-password.
|
| Specifically, to construct the PA-PK-AS-DH-REQ message, the user
| computes g = 2 * hashed-password,
| chooses a random number Ra, and
| computes Qa = g^Ra modulo p.
| After receiving the PA-PK-AS-DH-REQ message, the KDC
| chooses a random Rb,
| computes g = 2 * hashed-password,
| computes K = Qa^(2 * Rb) modulo p,
| verifies that K != 1, and
| computes Qb = g^(2 * Rb) modulo p.
| After receiving the PA-PK-AS-DH-REP message, the user:
| computes K = Qb^(2 * Ra) modulo p, and
| verifies that K is not 1.
| If either party detects that K is 1, the exchange is aborted.
|
|3.4.2 Diffie-Hellman Encrypted Key Exchange
|
| When using FLAVOR_DHEKE_MODP, a "safe prime" p is used
| of the form p = 2q+1, where the value of p is close to a power of 2,
| and where q is prime. The base g for the Diffie-Hellman exchange
| is a fixed primitive root of p, typically a small integer such as 2.
| The "public" exponentials are encrypted in both directions using
| the hashed-password as a symmetric key.
|
| Specifically, to construct the PA-PK-AS-DH-REQ message, the user
| chooses a random number Ra,
| computes Q = g^Ra modulo p, and
| encrypts Q using the hashed-password as a key to create Qa.
| After receiving the PA-PK-AS-DH-REQ message, the KDC
| chooses a random Rb,
| decrypts Qa to obtain Qa',
| computes K = Qa'^Rb modulo p,
| computes Qb' = g^Rb modulo p, and
| encrypts Qb' with the hashed-password as a key to get Qb.
| After receiving the PA-PK-AS-DH-REP message, the user:
| computes K = Qb^Ra modulo p.
|
|3.5. Retrieving the Private Key From the KDC
[...]
|3.5.1. Additional Protection of Retrieved Private Keys
| Without using some form of public-key preauthentication,
| the return of a private key, which is only protected by
| the user's password, presents an opportunity for brute-force
| attack on the password.
|
| One solution to the problem is to use password-authenticated key
| exchange for initial authentication, and additionally
| super-encrypt the returned private key using the jointly-derived
| one-time key.
============================================
Another possibility (not shown here) is to incorporate these methods in
a way that allows for the DH exchange to be both password-authenticated
*and* PK-signed, to give additional security. The theory being that
both locally stored keys and memorized keys have different strengths
and weaknesses, so why not allow both?
Comments appreciated.
------------------------------------
David P. Jablon
Integrity Sciences, Inc.
tel: +1 508 898 9024
web: http://world.std.com/~dpj/
email: dpj at world.std.com
Received: from ietf.org by ietf.org id aa09428; 2 Jun 97 13:00 EDT
Received: from casa.usno.navy.mil by ietf.org id aa09238; 2 Jun 97 12:54 EDT
Received: by CasA.usno.navy.mil
(1.37.109.24/16.2) id AA056930071; Mon, 2 Jun 1997 12:47:51 -0400
Date: Mon, 2 Jun 1997 12:47:51 -0400
Sender:ietf-request at ietf.org
From: marshall eubanks <tme at casa.usno.navy.mil>
To: ietf at ietf.org
Subject: Washington Post on Internet Trademarks
Message-ID: <9706021254.aa09238 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
People might be interested in a article in today's
Washington Post on the battle over the Trademark
on "Internet", page F17 in the Monday
business section, or
http://www.washingtonpost.com/wp-srv/WPlate/1997-06/02/026L-060297-idx.html
Regards
Marshall Eubanks
tme at casa.usno.navy.mil
Received: from ietf.org by ietf.org id aa09815; 2 Jun 97 13:23 EDT
Received: from bells.cs.ucl.ac.uk by ietf.org id aa09742; 2 Jun 97 13:22 EDT
Received: from rat.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.26938-0 at bells.cs.ucl.ac.uk>; Mon, 2 Jun 1997 18:17:36 +0100
To: marshall eubanks <tme at casa.usno.navy.mil>
cc: ietf at ietf.org
Subject: Re: Washington Post on Internet Trademarks
In-reply-to: Your message of "Mon, 02 Jun 1997 12:47:51 EDT." <9706021254.aa09238 at ietf.org>
Date: Mon, 02 Jun 1997 18:17:32 +0100
Message-ID: <1500.865271852 at cs.ucl.ac.uk>
Sender:ietf-request at ietf.org
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Source-Info: From (or Sender) name not authenticated.
>People might be interested in a article in today's
>Washington Post on the battle over the Trademark
thanks for the pointer...
>on "Internet", page F17 in the Monday
>business section, or
this is US trademark, only, right?
so we
(in the profitable part of the world)
all have the Internet -
and you'all
(where the main profitable business is being a lawyer)
can have the Outernet...assuming that hasn't been patented (though you
could challenge that on the grounds of obviousness or prior art e.g.
in the matrix...)
anyhow, i thought trademarks could co-exist if they were in different
areas of business - like theirs is cash-points, and ours is
cache-points
:-)
>http://www.washingtonpost.com/wp-srv/WPlate/1997-06/02/026L-060297-idx.html
jon
Received: from cnri by ietf.org id aa11098; 2 Jun 97 14:12 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09422;
2 Jun 97 14:12 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <QAA16488 at pad-thai.cam.ov.com>; Mon, 2 Jun 1997 16:23:31 GMT
Message-Id: <33937200.25B8 at frcl.bull.fr>
Date: Mon, 02 Jun 1997 18:23:12 -0700
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
Mime-Version: 1.0
To: John Linn <linn at cam.ov.com>
Cc: CAT-IETF WG <cat-ietf at mit.edu>
Subject: Re: Snego & GSS V2
References: <199706021341.JAA13968 at gza-client1.cam.ov.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
John Linn wrote:
>
> Denis writes:
>
> > Note : If we enrich, for backward compatibility, GSS_init_sec_context
> > should be kept unchanged and thus it would make sense to have new APIs.
>
> I agree. One question, though: on p. 7 of snego-05, it's stated that
> "The context flags should be filled in from the req_flags parameter of
> init_sec_context()." Is it necessarily required that the req_flags inputs
> will always be copied precisely into the emitted token, or is it acceptable
> for lower implementation layers within the client system to filter or
> modify the client requests?
This is a minor detail. Do you wish something local security policy
dependent ? We can add a sentence to specify so.
Denis
--
Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from ietf.org by ietf.org id aa13649; 2 Jun 97 16:09 EDT
Received: from dns1.Cent.Org by ietf.org id aa13513; 2 Jun 97 16:04 EDT
Received: from localhost (qjansen at localhost)
by dns1.cent.org (8.8.5/8.8.5) with SMTP id NAA04269
for <ietf at ietf.org>; Mon, 2 Jun 1997 13:09:01 -0700 (PDT)
Date: Mon, 2 Jun 1997 13:09:01 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Quinton Jansen <qjansen at dns1.cent.org>
To: ietf at ietf.org
Subject: Java has a simular problem to the 2000-year problem
Message-ID: <Pine.BSF.3.95q.970602130813.4168B-100000 at dns1.cent.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Quote from Information Week, May 19, 1997, pg. 12
"TIME IS ON JAVA'S SIDE
Sun Microsystems acknowledged last week thaat the Java programming
language has a year 2000-like date error: It will run out of dates in the
year 292271023. Yes, thats roughly 292 million years from now.
James Gosling, creator of Java, insists a team of engineers is rushing to
fix the problem. "We can't be certain Java will be around that long," he
kids, "but then again, we can't take any chances."
In case you were wondering, the year 292271023 is the estimated date for
the year 2000 fix at the IRS."
Thought that you might find it interesting!
Quinton
Received: from ietf.org by ietf.org id aa02015; 3 Jun 97 6:42 EDT
Received: from alpha1.Reston.mci.net by ietf.org id aa01889; 3 Jun 97 6:25 EDT
Received: from vcerf.mci.net ([166.55.72.247])
by ALPHA1.RESTON.MCI.NET (PMDF V5.1-8 #8388)
id <01IJMJOAIV4G001UM2 at ALPHA1.RESTON.MCI.NET> for ietf at ietf.org; Tue,
3 Jun 1997 06:21:09 EDT
Received: from vcerf.mci.net ([166.55.72.247])
by ALPHA1.RESTON.MCI.NET (PMDF V5.1-8 #8388)
with SMTP id <01IJMJO654Z2001TTI at ALPHA1.RESTON.MCI.NET> for ietf at ietf.org;
Tue, 03 Jun 1997 06:21:08 -0400 (EDT)
Date: Tue, 03 Jun 1997 06:13:49 -0400
Sender:ietf-request at ietf.org
From: "vinton g. cerf" <vcerf at mci.net>
Subject: Re: Washington Post on Internet Trademarks
X-Sender: vcerf at alpha1.reston.mci.net
To: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>,
marshall eubanks <tme at casa.usno.navy.mil>
Cc: ietf at ietf.org
Message-id: <3.0.32.19970603061317.00ac4a10 at alpha1.reston.mci.net>
MIME-version: 1.0
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Content-type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
Jon,
there are many claims on various uses of "internet" around
the world. The Internet Society has run into problems everywhere
it has filed for "internet Society" trademark.
The most egregious, however, is Internet, Inc's filing since
the filed in 1990 over protests by Bob Kahn and me.
ISOC and CNRI could use help fighting this - a campaign is costly and
really, the term ought to be accessible to everyone to use
to describe the products and services they offer. ISOC and
CNRI have jointly filed to cancel the trademark registration
of Internet, Inc. and have spent over $100K on legal fees so
far.
Send your contributions to free "internet" to
Internet Society
12020 Sunrise Valley Drive, Suite 210
Reston, VA 20191
attn: trademark fund
Vint
At 06:17 PM 6/2/97 +0100, Jon Crowcroft wrote:
>
>
> >People might be interested in a article in today's
> >Washington Post on the battle over the Trademark
>
>thanks for the pointer...
>
> >on "Internet", page F17 in the Monday
> >business section, or
>
>
>this is US trademark, only, right?
the problems are not only in the U.S.
>
>so we
>(in the profitable part of the world)
>all have the Internet -
>and you'all
>(where the main profitable business is being a lawyer)
>can have the Outernet...assuming that hasn't been patented (though you
>could challenge that on the grounds of obviousness or prior art e.g.
>in the matrix...)
>
>anyhow, i thought trademarks could co-exist if they were in different
>areas of business - like theirs is cash-points, and ours is
>cache-points
yes, they can co-exist where there is no conflict but Internet,
Inc filed against Internet Society in several categories, so
this is not a simple matter of splitting up territory.
>
>:-)
>
> >http://www.washingtonpost.com/wp-srv/WPlate/1997-06/02/026L-060297-idx.html
>
> jon
>
>
Received: from ietf.org by ietf.org id aa07556; 3 Jun 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa06794; 3 Jun 97 9:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-katsube-mpls-over-svc-00.txt
Date: Tue, 03 Jun 1997 09:55:20 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706030955.aa06794 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IP Address Resolution and ATM Signaling for MPLS over
ATM SVC services
Author(s) : H. Esaki, Y. Katsube, K. Nagami,
P. Doolan, Y. Rekhter
Filename : draft-katsube-mpls-over-svc-00.txt
Pages : 7
Date : 05/29/1997
Enabling interconnection of ATM Label Switching Routers (ATM-LSRs) over
standard ATM switch networks is desirable in order to introduce MPLS
technology into emerging ATM-LAN/WAN platform. This draft describes how
ATM-LSRs may interoperate with other ATM-LSRs over ATM UNI SVC services.
The two aspects of the problem that we address are ATM address (of target
ATM-LSR) resolution and SVC to label binding.
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-katsube-mpls-over-svc-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-katsube-mpls-over-svc-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-katsube-mpls-over-svc-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970529105528.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-katsube-mpls-over-svc-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-katsube-mpls-over-svc-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970529105528.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07580; 3 Jun 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa06905; 3 Jun 97 9:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-hoffman-smtp-ssl-03.txt
Date: Tue, 03 Jun 1997 09:55:44 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706030955.aa06905 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : SMTP Service Extension for Secure SMTP over TLS
Author(s) : P. Hoffman
Filename : draft-hoffman-smtp-ssl-03.txt
Pages : 4
Date : 06/02/1997
This document describes an extension to the SMTP service that allows an
SMTP server and client to use transport-layer security to provide private,
authenticated communication over the Internet. This gives SMTP agents the
ability to protect some or all of their communications from eavesdroppers
and attackers.
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-hoffman-smtp-ssl-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hoffman-smtp-ssl-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-hoffman-smtp-ssl-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970602114056.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hoffman-smtp-ssl-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hoffman-smtp-ssl-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970602114056.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07566; 3 Jun 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa06947; 3 Jun 97 9:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-acap+ at andrew.cmu.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-acap-mlsf-00.txt
Date: Tue, 03 Jun 1997 09:55:47 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706030955.aa06947 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 Application Configuration
Access Protocol Working Group of the IETF.
Title : Multi-Lingual String Format (MLSF)
Author(s) : C. Newman
Filename : draft-ietf-acap-mlsf-00.txt
Pages : 12
Date : 06/02/1997
While UTF-8 [UTF-8] solves most internationalization (I18N) problems, it
fails to solve multilingualization problems (M17N) problems. The two basic
problems with UTF-8 are that CJK unification fails to recognize glyph style
differences between Chinese, Japanese and Korean and that it is impossible
to read UTF-8 text to a blind person without knowing the language.
Encoding language tagging in the coded character set itself can
unnecessarily complicate processing which doesn't need language tags.
Encoding the language tagging at the application protocol level will add
unnecessary complexity to every application protocol which needs
multi-lingual support. In addition, such higher level language support may
fail to deal with mixed language strings and strings which have alternate
representations in different languages.
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-acap-mlsf-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-acap-mlsf-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-acap-mlsf-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970602115354.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-acap-mlsf-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-acap-mlsf-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970602115354.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07561; 3 Jun 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa07176; 3 Jun 97 9:56 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: trunk-mib at cisco.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-trunkmib-ds0-mib-04.txt
Date: Tue, 03 Jun 1997 09:56:20 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706030956.aa07176 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the DS1/DS3 MIB Working Group of
the IETF.
Note: This revision reflects comments received during the last call period.
Title : Definitions of Managed Objects for the DS0 and DS0
Bundle Interface Type
Author(s) : D. Fowler
Filename : draft-ietf-trunkmib-ds0-mib-04.txt
Pages : 20
Date : 06/02/1997
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for managing DS0 and
DS0 Bundle interfaces. This document is a companion document with
Definitions of Managed Objects for the DS1/E1/DS2/E2, DS3/E3 and SONET/SDH
Interface Types, rfcTBD [6], rfcTBD [7] and rfc1595 [8].
This memo specifies a MIB module in a manner that is both compliant to the
SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-trunkmib-ds0-mib-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-trunkmib-ds0-mib-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-trunkmib-ds0-mib-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970602171128.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-trunkmib-ds0-mib-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-trunkmib-ds0-mib-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970602171128.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07564; 3 Jun 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa06868; 3 Jun 97 9:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
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-as-map-04.txt
Date: Tue, 03 Jun 1997 09:55:36 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706030955.aa06868 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 : Mapping Autonomous Systems Number into the Domain Name
System
Author(s) : D. Eastlake
Filename : draft-ietf-dnssec-as-map-04.txt
Pages : 8
Date : 06/02/1997
One requirement of secure routing is that independent routing entities,
such as those identified by Internet Autonomous System Numbers, be able to
authenticate messages to each other. Additions have developed to the
Domain Name System to enable it to be used for authenticated public key
distribution [RFC 2065]. This draft maps all Autonomous System numbers
into DNS Domain Names so that the DNS can be used to distribute their
public keys.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dnssec-as-map-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-as-map-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dnssec-as-map-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970602151701.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnssec-as-map-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnssec-as-map-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970602151701.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07571; 3 Jun 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa06832; 3 Jun 97 9:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: tn3270e at list.nih.gov
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-tn3270e-tn3270-mib-00.txt
Date: Tue, 03 Jun 1997 09:55:25 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706030955.aa06832 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 Telnet TN3270 Enhancements
Working Group of the IETF.
Title : Definitions of Managed Objects for TN3270 Using SMIv2
Author(s) : K. White
Filename : draft-ietf-tn3270e-tn3270-mib-00.txt
Pages : 33
Date : 06/02/1997
The purpose of this memo is to define the Management Information Base (MIB)
for configuring and monitoring TN3270 and TN3270E sessions. The monitoring
portion of the MIB is limited to AUGMENTation of the TCP Connection Table
(RFC 2012) with a set of objects collected from the TCP Layer. It is the
intent of this MIB to fully adhere to all prerequisite MIBs unless
explicitly stated. Deviations will be documented in corresponding
conformance statements. The specification of this MIB will utilize the
Structure of Management Information (SMI) for Version 2 of the Simple
Network Management Protocol Version (refer to RFC1902, reference [1]).
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-tn3270e-tn3270-mib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-tn3270e-tn3270-mib-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-tn3270e-tn3270-mib-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970602100632.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-tn3270e-tn3270-mib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tn3270e-tn3270-mib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970602100632.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07578; 3 Jun 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa06813; 3 Jun 97 9:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
cc: saag at tis.com
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-eastlake-weak-ato-01.txt
Date: Tue, 03 Jun 1997 09:55:23 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706030955.aa06813 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The Weak Authentication and Tracing Option
Author(s) : D. Eastlake
Filename : draft-eastlake-weak-ato-01.txt
Pages : 22
Date : 06/02/1997
The packet switched nature of the Internet Protocol (IP) provides no
inherent method to assure that a packet has been issued with a source
address authorized for use by the sender and no inherent method to trace
the actual source of a packet. These characteristics make it difficult to
take effective action concerning injurious packets which may have
originated, by accident or maliciously, virtually anywhere in the Internet.
A lightweight IP level option is proposed that provides (1) some assurance
that packets are authorized by a host along the path routed through when
the packet's source address is used as a destination address, and (2)
limited statistical tracing information such that, if many bad packets are
logged, the path to their source will usually be revealed. This would
provide significantly improved protection against packet level abuse.
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-eastlake-weak-ato-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-eastlake-weak-ato-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-eastlake-weak-ato-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970602100001.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-eastlake-weak-ato-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-eastlake-weak-ato-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970602100001.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07552; 3 Jun 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa06887; 3 Jun 97 9:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-budge-media-error-correction-00.txt
Date: Tue, 03 Jun 1997 09:55:41 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706030955.aa06887 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Media-independent Error Correction using RTP
Author(s) : D. Budge, R. McKenzie, W. Mills, W. Diss, P. Long
Filename : draft-budge-media-error-correction-00.txt
Pages : 17
Date : 06/02/1997
This document specifies a media-independent error-correction scheme using
the Real-Time Transport Protocol (RTP), along with the payload format for
encapsulating both error-correction signaling and media bitstreams in RTP.
It enables the reconstruction of lost packets across a connectionless
transport such as RTP over UDP. The goal of this scheme is to maximize
isochrony, the regular and timely delivery of data, with minimal bandwidth,
latency, and computational costs.
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-budge-media-error-correction-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-budge-media-error-correction-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-budge-media-error-correction-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970602105525.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-budge-media-error-correction-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-budge-media-error-correction-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970602105525.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07579; 3 Jun 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa07139; 3 Jun 97 9:56 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: trunk-mib at cisco.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-trunkmib-ds3-mib-05.txt
Date: Tue, 03 Jun 1997 09:56:12 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706030956.aa07139 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the DS1/DS3 MIB Working Group of
the IETF.
Note: This revision reflects comments received during the last call period.
Title : Definitions of Managed Objects for the DS3/E3 Interface
Type
Author(s) : D. Fowler
Filename : draft-ietf-trunkmib-ds3-mib-05.txt
Pages : 64
Date : 06/02/1997
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for managing DS3 and
E3 interfaces. This document is a companion document with Definitions of
Managed Objects for the DS0, DS1/E1/DS2/E2 and SONET/SDH Interface Types,
rfcTBD [14], rfcTBD [6] and rfcTBD [7].
This memo specifies a MIB module in a manner that is both compliant to the
SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
This memo does not specify a standard for the Internet community.
This document entirely replaces RFC 1407.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-trunkmib-ds3-mib-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-trunkmib-ds3-mib-05.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-trunkmib-ds3-mib-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970602170814.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-trunkmib-ds3-mib-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-trunkmib-ds3-mib-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970602170814.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07577; 3 Jun 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa06994; 3 Jun 97 9:56 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
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-scsp-nhrp-01.txt
Date: Tue, 03 Jun 1997 09:55:58 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706030956.aa06994 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 : A Distributed NHRP Service Using SCSP
Author(s) : J. Luciani
Filename : draft-ietf-ion-scsp-nhrp-01.txt
Pages : 6
Date : 04/16/1997
This document describes a method for distributing an NHRP service within a
LIS[1]. This method uses the Server Cache Synchronization Protocol
(SCSP)[2] to synchronize the client information databases held by NHRP
Servers (NHSs) within a LIS.
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-scsp-nhrp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-scsp-nhrp-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ion-scsp-nhrp-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970602144414.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-scsp-nhrp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-scsp-nhrp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970602144414.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08756; 3 Jun 97 10:44 EDT
Received: from ietf.ietf.org by ietf.org id aa06976; 3 Jun 97 9:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-ldapv3-tls-00.txt
Date: Tue, 03 Jun 1997 09:55:56 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706030955.aa06976 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : Lightweight Directory Access Protocol (v3): Extension
for Transport Layer Security
Author(s) : J. Hodges, B. Morgan, M. Wahl
Filename : draft-ietf-asid-ldapv3-tls-00.txt
Pages : 7
Date : 06/02/1997
This document defines the "Start Transport Layer Security (TLS)
Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS
establishment in an LDAP association and is defined in terms of an LDAP
extended operation.
The key words "MUST", "SHOULD", and "MAY" used in this document are to be
interpreted as described in [Bradner97].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-asid-ldapv3-tls-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3-tls-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-ldapv3-tls-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970602132437.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldapv3-tls-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldapv3-tls-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970602132437.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa11750; 3 Jun 97 13:26 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09264;
3 Jun 97 13:26 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <PAA27394 at pad-thai.cam.ov.com>; Tue, 3 Jun 1997 15:09:57 GMT
Message-Id: <199706031509.LAA16481 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: D.Pinkas at frcl.bull.fr
Cc: John Linn <linn at cam.ov.com>, CAT-IETF WG <cat-ietf at mit.edu>,
linn at cam.ov.com
Subject: Re: Snego & GSS V2
In-Reply-To: Your message of "Mon, 02 Jun 1997 18:23:12 PDT."
<33937200.25B8 at frcl.bull.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 03 Jun 1997 11:09:51 -0400
From: John Linn <linn at cam.ov.com>
Precedence: bulk
It seems reasonable to me to allow (but not require) the possibility that
local policy or configuration might modify the caller's requests. Unless
others object, I suggest that this be permitted.
--jl
> John Linn wrote:
> >
> > Denis writes:
> >
> > > Note : If we enrich, for backward compatibility, GSS_init_sec_context
> > > should be kept unchanged and thus it would make sense to have new APIs.
> >
> > I agree. One question, though: on p. 7 of snego-05, it's stated that
> > "The context flags should be filled in from the req_flags parameter of
> > init_sec_context()." Is it necessarily required that the req_flags inputs
> > will always be copied precisely into the emitted token, or is it acceptable
> > for lower implementation layers within the client system to filter or
> > modify the client requests?
>
> This is a minor detail. Do you wish something local security policy
> dependent ? We can add a sentence to specify so.
>
> Denis
>
> --
>
> Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
> Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
> 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
>
Received: from ietf.org by ietf.org id aa12655; 3 Jun 97 14:02 EDT
Received: from zephyr.isi.edu by ietf.org id aa12541; 3 Jun 97 13:59 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
id <AA03023>; Tue, 3 Jun 1997 10:55:30 -0700
Message-Id: <199706031755.AA03023 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2152 on UTF-7
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 03 Jun 97 10:55:26 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 2152:
Title: UTF-7
A Mail-Safe Transformation Format of Unicode
Author: D. Goldsmith, M. Davis
Date: May 1997
Mailbox: goldsmith at apple.com, mark_davis at taligent.com
Pages: 15
Characters: 28065
Obsoletes: 1642
URL: ftp://ds.internic.net/rfc/rfc2152.txt
This document describes a transformation format of Unicode that
contains only 7-bit ASCII octets and is intended to be readable by
humans in the limiting case that the document consists of characters
from the US-ASCII repertoire. It also specifies how this
transformation format is used in the context of MIME and RFC 1641,
"Using Unicode with MIME".
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970603104943.RFC at ISI.EDU>
SEND /rfc/rfc2152.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2152.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970603104943.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13114; 3 Jun 97 14:26 EDT
Received: from zephyr.isi.edu by ietf.org id aa13077; 3 Jun 97 14:25 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
id <AA04729>; Tue, 3 Jun 1997 11:21:41 -0700
Message-Id: <199706031821.AA04729 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2153 on PPP Vendor Extensions
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 03 Jun 97 11:21:40 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 2153:
Title: PPP Vendor Extensions
Author: W. Simpson
Date: May 1997
Mailbox: wsimpson at GreenDragon.com
Pages: 6
Characters: 10780
Updates: 1661, 1962
URL: ftp://ds.internic.net/rfc/rfc2153.txt
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP
defines an extensible Link Control Protocol (LCP) for establishing,
configuring, and testing the data-link connection; and a family of
Network Control Protocols (NCPs) for establishing and configuring
different network-layer protocols. This document defines a general
mechanism for proprietary vendor extensions. This document is a
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 IETF.ORG. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970603105753.RFC at ISI.EDU>
SEND /rfc/rfc2153.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2153.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970603105753.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06360; 4 Jun 97 9:54 EDT
Received: from ietf.ietf.org by ietf.org id aa05710; 4 Jun 97 9:27 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-srisuresh-00.txt
Date: Wed, 04 Jun 1997 09:27:14 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706040927.aa05710 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The IP Network Address Translator (NAT)
Author(s) : P. Srisuresh, K. Egevang
Filename : draft-rfced-info-srisuresh-00.txt
Pages : 16
Date : 06/03/1997
Basic Network Address Translation or Basic NAT is a feature by which IP
addresses are mapped from one group to another, transparent to users.
Network Address Port Translation, or NAPT is an extension to Basic NAT, in
that many network addresses and their TCP/UDP ports are translated to a
single network address and its TCP/UDP ports.
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-srisuresh-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-srisuresh-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-srisuresh-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970604091127.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-srisuresh-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-srisuresh-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970604091127.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06359; 4 Jun 97 9:54 EDT
Received: from ietf.ietf.org by ietf.org id aa05687; 4 Jun 97 9:27 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-teraoka-ipv6-mobility-sup-04.txt
Date: Wed, 04 Jun 1997 09:27:09 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706040927.aa05687 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Mobility Support in IPv6
Author(s) : F. Teraoka
Filename : draft-teraoka-ipv6-mobility-sup-04.txt
Pages : 14
Date : 06/03/1997
This memo describes a protocol to support mobility in IPv6. The mobile
node has an identifier (home address) and a temporary address (care-of
address). The IPv6 base header includes the temporary addresses so that
the source and destination addresses are always topologically significant,
while the identifiers are included in the Destination Options Header. End
nodes may have authentic cache information between identifiers and
addresses for routing optimization. This protocol introduces two new
destination options: `Source Identifier' and `Destination Identifier', and
also introduces two control packets using UDP.
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-teraoka-ipv6-mobility-sup-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-teraoka-ipv6-mobility-sup-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-teraoka-ipv6-mobility-sup-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970603105823.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-teraoka-ipv6-mobility-sup-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-teraoka-ipv6-mobility-sup-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970603105823.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06364; 4 Jun 97 9:54 EDT
Received: from ietf.ietf.org by ietf.org id aa05793; 4 Jun 97 9:28 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: idr at merit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-idr-bgp4-06.txt
Date: Wed, 04 Jun 1997 09:27:06 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706040928.aa05793 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-06.txt
Pages : 59
Date : 06/03/1997
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-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-06.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-idr-bgp4-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970603104451.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idr-bgp4-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970603104451.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06367; 4 Jun 97 9:54 EDT
Received: from ietf.ietf.org by ietf.org id aa05819; 4 Jun 97 9:28 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ospf at gated.cornell.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-ospf-nssa-update-02.txt
Date: Wed, 04 Jun 1997 09:27:03 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706040928.aa05819 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 Open Shortest Path First IGP
Working Group of the IETF.
Title : The OSPF NSSA Option
Author(s) : R. Coltun, V. Fuller, P. Murphy
Filename : draft-ietf-ospf-nssa-update-02.txt
Pages : 25
Date : 06/03/1997
This memo documents of an optional type of OSPF area which is somewhat
humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are
similar to the existing OSPF stub area configuration option but have the
additional capability of importing AS external routes in a limited fashion.
The OSPF NSSA Option was originally defined in RFC 1587. The functional
differences between this memo and RFC 1587 are explained in Appendix D.
All differences, while expanding capability, are backward-compatible in
nature. Implementations of this memo and of RFC 1587 will interoperate.
Please send comments to ospf at gated.cornell.edu.
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-ospf-nssa-update-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ospf-nssa-update-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ospf-nssa-update-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
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: <19970603101502.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-nssa-update-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ospf-nssa-update-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970603101502.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06365; 4 Jun 97 9:54 EDT
Received: from ietf.ietf.org by ietf.org id aa05727; 4 Jun 97 9:27 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-gwinn-01.txt
Date: Wed, 04 Jun 1997 09:27:16 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706040927.aa05727 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Network Security For Trade Shows
Author(s) : A. Gwinn
Filename : draft-rfced-info-gwinn-01.txt
Pages : 9
Date : 06/03/1997
This draft is designed to assist vendors and other participants in trade
shows, such as Networld+Interop, in designing effective protection against
network and system attacks by unauthorized individuals. Generally, it has
been observed that many system administrators and trade show coordinators
tend to overlook the importance of system security at trade shows. In fact,
systems at trade shows are at least as prone to attack as office-based
platforms. Trade show systems should be treated as seriously as an office
computer. A breach of security of a trade show system can render -- and has
rendered -- an exhibitor's demonstrations inoperable -- sometimes for the
entire event!
This draft is not intended to replace the multitudes of comprehensive books
on the subject of Internet security. Rather, its purpose is to provide
a checklist-style collection of frequently overlooked, simple ways
to minimize the chance of a costly attack. We encourage exhibitors
to pay special attention to this document and share it with all
associated representatives.
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-gwinn-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-gwinn-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-gwinn-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970603140552.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-gwinn-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-gwinn-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970603140552.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06580; 5 Jun 97 10:23 EDT
Received: from ietf.ietf.org by ietf.org id aa05951; 5 Jun 97 9:59 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: urn-ietf at bunyip.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-urn-req-frame-02.txt
Date: Thu, 05 Jun 1997 09:59:08 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706050959.aa05951 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Names
Working Group of the IETF.
Title : Guidelines and a Framework for URN Resolution Systems
Author(s) : K. Sollins
Filename : draft-ietf-urn-req-frame-02.txt
Pages : 19
Date : 06/04/1997
This document addresses the issues of the discovery of URN resolver
services that in turn will directly translate URNs into URLs and URCs. The
document falls into three major parts, the assumptions underlying the work,
the guidelines in order to be a viable Resolver Discovery Service or RDS to
help in finding URN resolvers, and a framework for designing RDSs. The
guidelines fall into three major areas: evolvability, usability, and
security and privacy. An RDS that is compliant with the framework will not
necessarily be compliant with the guidelines. Compliance with the
guidelines will need to be validated separately.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-urn-req-frame-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-req-frame-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-urn-req-frame-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970604175242.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-urn-req-frame-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-urn-req-frame-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970604175242.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06575; 5 Jun 97 10:23 EDT
Received: from ietf.ietf.org by ietf.org id aa05903; 5 Jun 97 9:59 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: disman 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-disman-express-mib-02.txt
Date: Thu, 05 Jun 1997 09:59:01 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706050959.aa05903 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 Distributed Management
Working Group of the IETF.
Title : Expression MIB
Author(s) : B. Stewart
Filename : draft-ietf-disman-express-mib-02.txt
Pages : 30
Date : 06/04/1997
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
expressions of MIB objects.
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-disman-express-mib-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-disman-express-mib-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-disman-express-mib-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970604110303.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-disman-express-mib-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-disman-express-mib-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970604110303.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06577; 5 Jun 97 10:23 EDT
Received: from ietf.ietf.org by ietf.org id aa05921; 5 Jun 97 9:59 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
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-03.txt
Date: Thu, 05 Jun 1997 09:59:04 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706050959.aa05921 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internetworking Over NBMA
Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : IP Broadcast over ATM Networks
Author(s) : T. Smith, G. Armitage
Filename : draft-ietf-ion-bcast-03.txt
Pages : 14
Date : 06/04/1997
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 RFC 2022 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-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-bcast-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ion-bcast-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970604173648.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-bcast-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-bcast-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970604173648.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06574; 5 Jun 97 10:23 EDT
Received: from ietf.ietf.org by ietf.org id aa05950; 5 Jun 97 9:59 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ipp at pwg.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipp-model-01.txt
Date: Thu, 05 Jun 1997 09:59:06 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706050959.aa05950 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 Internet Printing Protocol
Working Group of the IETF.
Title : Internet Printing Protocol/1.0: Model and Semantics
Author(s) : R. Debry, T. Hastings, R. Herriot,
S. Isaacson, P. Powell
Filename : draft-ietf-ipp-model-01.txt
Pages : 82
Date : 06/04/1997
This document is one of a set of documents, which together describe all
aspects of a new Internet Printing Protocol (IPP). IPP is an application
level protocol that can be used for distributed printing using Internet
tools and technology. The protocol is heavily influenced by the printing
model introduced in the Document Printing Application (ISO/IEC 10175 DPA)
standard. Although DPA specifies both end user and administrative
features, IPP version 1.0 is focused only on end user functionality.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipp-model-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipp-model-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970604174841.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipp-model-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipp-model-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970604174841.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa10564; 5 Jun 97 14:06 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10250;
5 Jun 97 14:06 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <QAA10501 at pad-thai.cam.ov.com>; Thu, 5 Jun 1997 16:21:44 GMT
Message-Id: <3.0.32.19970605092130.00a7dc30 at pop-srvr>
X-Sender: eyala at pop-srvr
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 05 Jun 1997 09:21:30 -0700
To: cat-ietf at mit.edu
From: Eyal Askenazi <eyal.askenazi at cybersafe.com>
Subject: subscribe
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
subscribe
Received: from ietf.org by ietf.org id aa13911; 5 Jun 97 17:52 EDT
Received: from Riverside.MR.Net by ietf.org id aa13769; 5 Jun 97 17:45 EDT
Received: from www (ded-open.InnovSoftD.com [207.1.200.27])
by riverside.mr.net (8.8.5/) with ESMTP id QAA16393
for <ietf at ietf.org>; Thu, 5 Jun 1997 16:41:31 -0500 (CDT)
Message-Id: <199706052141.QAA16393 at riverside.mr.net>
Sender:ietf-request at ietf.org
From: Jon Davis <newbreed at isd.net>
To: ietf at ietf.org
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: Tagging scheme mailing list
Date: Thu, 5 Jun 1997 16:51:16 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
IETF members,
A few months ago I sent a proposal to this list dealing with the tagging of
spam. (http://www.winternet.com/~mackie/spam) Due to the lack of response
on the IETF's part (which is understandable), a mailing list from outside
the IETF has been established, which specifically pertains to the technical
matters of the tag itself. Everyone in the IETF is welcome, we could use
some educated brainpower.
I apologize if you consider this a spam, but since the proposal was
originally drawn up for you in the first place, I felt you should know
where it is heading, and how you can get involved, if indeed you even
care--which, in most cases, isn't very likely. Those of us who are
interested, however, in dealing with uncontrolled spam are anxious to get
this thing going.
To join the list, send a message to listserv at interact-net.com with the body
"join spam-tag".
Regards,
Jon Davis
President, NewBreed Communications
http://www.interact-net.com
Received: from cnri by ietf.org id aa13972; 5 Jun 97 17:54 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13301;
5 Jun 97 17:54 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <UAA08408 at pad-thai.cam.ov.com>; Thu, 5 Jun 1997 20:50:40 GMT
Message-Id: <199706052050.AA15132 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: Snego & GSS V2
To: D.Pinkas at frcl.bull.fr
Date: Thu, 5 Jun 1997 16:49:17 -0400 (EDT)
Cc: cat-ietf at mit.edu
In-Reply-To: <338DE495.465A at frcl.bull.fr> from "Denis Pinkas" at May 29, 97 01:18:29 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Denis Pinkas wrote:
>
> SNEGO, PNEGO, SPNEGO, CNEGO or CPNEGO ? with C=Complex :-)
>
> The negotiation mechanism described in the current draft is giving
> exactly the same features as the GSS-API V2. In particular, it is not
> possible to know in advance whether confidentiality and integrity will
> be available (although most mechanisms support this feature). The
> paradigm is: if you do not like what you got, you destroy the context.
>
> The basic question is whether we want (1) to stay like this, (2) enrich
> the current functionality of GSS-API V2 so that it becomes available on
> GSS-API V2 or (3) enrich the current functionality of SPNEGO so that it
> becomes available on CPNEGO only.
I strongly favour (3). (expl. follows)
>
> Martin as made a proposal along the option (3) that applies to the
> optional APIs described in the annex of SPNEGO. If we follow that
> proposal, that will end-up with flags that are present in the protocols
> that can only be set by these APIs. This would thus make sense to
> consider the APIs in the main body of SPNEGO or ... of GSS-API V2+.
>
> Note : If we enrich, for backward compatibility, GSS_init_sec_context
> should be kept unchanged and thus it would make sense to have new APIs.
Yes, we should keep gss_init_sec_context() backward compatibility.
>
> I would favor two additional APIs, independent from GSS_Get_neg_mechs
> and GSS_Set_neg_mechs that would allow to specify the flags and make it
> part of GSS-API V2+ so that the functionality becomes available whether
> a precise mech is specified or the negotiation mechanism is specified.
The original request from Mike Swift was to have feature requirements
being considered for SELECTION of the best common mechanism, but to
still establish a security context even when the feature "requirements"
cannot be met.
If the requirements are to affect the *negotiation*, they have to part
of SPNEGO, not base GSS-API.
In one of my last mails I had a bad typo.
I wrote:
> ... the negotiation constraints should be transferred seperately
> from the feature request of gss_init_sec_context().
> But even negotiation constraining feature requests should
> prevent a successful context establishment without these features.
|
+---- insert 'NOT'
I think it's perfectly fine to end up with a security context, even when
the features that I wanted to be considered for the *negotiation* can
not be met.
It would be much easier (and "portable") for an application to
do a sensible negotiation by indicating prefererred features than
by creating a list of mechanisms with an order of preference.
An application should neither have to know or have to guess about
features or "quality" of the mechanisms that are currently installed,
because that is not really portable. If an application is concerned
about security aspects, it will first of all distinguish "unprotected",
"integrity-protected" and "confidentiality-protected".
A mechanism preference list should be created/maintained by the sysadmin/user
who installs the mechanisms. Features availablility from a mechanism
should either remain an (=non-standard) SPNEGO-configuration issue,
or be made inquire-able in base GSS-API (=standard).
IMHO for the application there is more value in constraining the
negotiation in terms of features (very portable) than in terms of
a mechanism preference lists (non-portable and messy, because it
(currently) really is installation- and product- specific).
>
> The consequence on SPNEGO would be to add another structure in the
> negotiation token like :
>
> MandatoryServices ::= BIT STRING {
> delegFlag (0),
> mutualFlag (1),
> replayFlag (2),
> sequenceFlag (3),
> anonFlag (4),
> confFlag (5),
> integFlag (6)
> }
The availability of some features may well be implementation specific
(versus mech-specific or context-related). This is especially obvious
for the features "trans_flag" and "prot_ready_flag" (which no-one
commented on -- I listed them in my proposal). Each side of the
connection will (at most/only) know about features of the locally
installed mechanism implementation! To be able for the context acceptor
to make a sensible decision, the initiator either has to send along all
his knowledge about the features of *every one of his* mechanisms
implementations plus the requested features, or (as in my proposal)
the initiator must adjust his mechanism preference list before sending
it plus include the requested features.
Sending along "trans_flag" and "prot_ready_flag" is not really useful, but
I'd really like to have them available as (local) negotiation constraints!
-Martin
Received: from ietf.org by ietf.org id aa01568; 6 Jun 97 4:00 EDT
Received: from cnri by ietf.org id aa01112; 6 Jun 97 3:42 EDT
Received: from [204.250.46.130] by CNRI.Reston.VA.US id aa02608;
6 Jun 97 3:42 EDT
Received: from belize.it.earthlink.net (ip211.phoenix.az.pub-ip.psi.net [38.11.190.211])
by belize.it.earthlink.net (8.8.5/8.8.5) with SMTP id AAA26044;
Fri, 6 Jun 1997 00:37:57 -0700 (PDT)
Sender:ietf-request at ietf.org
From: bodiesrhot at hotmail.com
Received: from mailhost.bstgrlsss.com (alt1.bstgrlsss.com(289.3.33.75) by bodiesrhot at hotmail.com (8.8.5/8.6.5) with SMTP id GAA02927 for <bodiesrhot at hotmail.com>; Fri, 06 Jun 1997 00:10:02 -0600 (EST)
To: bodiesrhot at hotmail.com
Message-ID: <184558452539.CAA08557 at bstgrlsss.com>
Date: Fri, 06 Jun 97 00:10:02 EST
Subject: Tiffany's Pictures on her web page
Reply-To: bodiesrhot at hotmail.com
X-UIDL: 15373155953585955312535201758432
Comments: Authenticated sender is <bodiesrhot at hotmail.com>
Source-Info: From (or Sender) name not authenticated.
If you are not interested in adult pictures or are under the age of
18, I apologize, DO NOT REPLY and I will GUARANTEE you will be
removed from my list or you may reply to removetif at answerme.com and
you will receive confirmation that you were removed, either way, I apologize
and you WILL be removed from my list.
Hi my name is Tiffany. I am a college student that just learned how
to make a web page, so I decided to put some naughty pictures of
myself on my page for everyone to see. If you want to see it, write
back to me at tif at answerme.com and type "over 18" in the subject box
(you will have to change the current "to" box to tif at answerme.com)
If you are offended by nudity, Do Not Reply and I will take you off
my mailing list.
-Tiffany
-Tiffany
Received: from ietf.org by ietf.org id aa03552; 6 Jun 97 7:07 EDT
Received: from ester.dsv.su.se by ietf.org id aa03459; 6 Jun 97 7:01 EDT
Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138])
by ester.dsv.su.se (8.7.1/8.7.1) with ESMTP
id MAA18715;
Fri, 6 Jun 1997 12:57:19 +0200 (MET DST)
X-Sender: jpalme at dsv.su.se (Unverified)
Message-Id: <v0300781cafbd8f207144 at [130.238.18.152]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 6 Jun 1997 11:56:43 +0200
To: cmc at cios.org, IETF general mailing list <ietf at ietf.org>
Sender:ietf-request at ietf.org
From: Jacob Palme <jpalme at dsv.su.se>
Subject: Usenet News
Source-Info: From (or Sender) name not authenticated.
A description with pictures of the main technical principles of Usenet News
can be found at URL:
http://www.dsv.su.se/~jpalme/e-mail-book/usenet-news.html
------------------------------------------------------------------------
Jacob Palme <jpalme at dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme
Received: from cnri by ietf.org id aa05637; 6 Jun 97 9:35 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa05846;
6 Jun 97 9:35 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <LAA27120 at pad-thai.cam.ov.com>; Fri, 6 Jun 1997 11:05:04 GMT
Message-Id: <33986D5E.724D at frcl.bull.fr>
Date: Fri, 06 Jun 1997 13:04:46 -0700
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
Mime-Version: 1.0
To: Martin.Rex at sap-ag.de
Cc: cat-ietf at mit.edu
Subject: Re: Snego & GSS V2
References: <199706052050.AA15132 at sap-ag.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Martin Rex wrote:
>
> Denis Pinkas wrote:
> >
> > SNEGO, PNEGO, SPNEGO, CNEGO or CPNEGO ? with C=Complex :-)
> >
> > The negotiation mechanism described in the current draft is giving
> > exactly the same features as the GSS-API V2. In particular, it is not
> > possible to know in advance whether confidentiality and integrity will
> > be available (although most mechanisms support this feature). The
> > paradigm is: if you do not like what you got, you destroy the context.
> >
> > The basic question is whether we want (1) to stay like this, (2) enrich
> > the current functionality of GSS-API V2 so that it becomes available on
> > GSS-API V2 or (3) enrich the current functionality of SPNEGO so that it
> > becomes available on CPNEGO only.
>
> I strongly favour (3). (expl. follows)
Looking at your explanations , I strongly favours (1) : stay like this
:-)
(expl. follows)
> > Martin as made a proposal along the option (3) that applies to the
> > optional APIs described in the annex of SPNEGO. If we follow that
> > proposal, that will end-up with flags that are present in the protocols
> > that can only be set by these APIs. This would thus make sense to
> > consider the APIs in the main body of SPNEGO or ... of GSS-API V2+.
> >
> > Note : If we enrich, for backward compatibility, GSS_init_sec_context
> > should be kept unchanged and thus it would make sense to have new APIs.
>
> Yes, we should keep gss_init_sec_context() backward compatibility.
>
> >
> > I would favor two additional APIs, independent from GSS_Get_neg_mechs
> > and GSS_Set_neg_mechs that would allow to specify the flags and make it
> > part of GSS-API V2+ so that the functionality becomes available whether
> > a precise mech is specified or the negotiation mechanism is specified.
>
> The original request from Mike Swift was to have feature requirements
> being considered for SELECTION of the best common mechanism, but to
> still establish a security context even when the feature "requirements"
> cannot be met.
>
> If the requirements are to affect the *negotiation*, they have to part
> of SPNEGO, not base GSS-API.
>
> In one of my last mails I had a bad typo.
> I wrote:
> > ... the negotiation constraints should be transferred seperately
> > from the feature request of gss_init_sec_context().
> > But even negotiation constraining feature requests should
> > prevent a successful context establishment without these features.
> |
> +---- insert 'NOT'
This makes a BIG difference ! I wonder what is the opinion from the
other members from the group.
This is what we have today and thus I do not see a reason for a change.
> I think it's perfectly fine to end up with a security context, even when
> the features that I wanted to be considered for the *negotiation* can
> not be met.
This feature is in the original spec. It is not really clear what you
are asking for.
> It would be much easier (and "portable") for an application to
> do a sensible negotiation by indicating prefererred features than
> by creating a list of mechanisms with an order of preference.
>
> An application should neither have to know or have to guess about
> features or "quality" of the mechanisms that are currently installed,
> because that is not really portable. If an application is concerned
> about security aspects, it will first of all distinguish "unprotected",
> "integrity-protected" and "confidentiality-protected".
> A mechanism preference list should be created/maintained by the sysadmin/user
> who installs the mechanisms. Features availablility from a mechanism
> should either remain an (=non-standard) SPNEGO-configuration issue,
> or be made inquire-able in base GSS-API (=standard).
Features availablility are not static and are target dependent.
Any way, IMHO, this question is independent from SPNEGO.
> IMHO for the application there is more value in constraining the
> negotiation in terms of features (very portable) than in terms of
> a mechanism preference lists (non-portable and messy, because it
> (currently) really is installation- and product- specific).
>
> >
> > The consequence on SPNEGO would be to add another structure in the
> > negotiation token like :
> >
> > MandatoryServices ::= BIT STRING {
> > delegFlag (0),
> > mutualFlag (1),
> > replayFlag (2),
> > sequenceFlag (3),
> > anonFlag (4),
> > confFlag (5),
> > integFlag (6)
> > }
>
> The availability of some features may well be implementation specific
> (versus mech-specific or context-related). This is especially obvious
> for the features "trans_flag" and "prot_ready_flag" (which no-one
> commented on -- I listed them in my proposal). Each side of the
> connection will (at most/only) know about features of the locally
> installed mechanism implementation! To be able for the context acceptor
> to make a sensible decision, the initiator either has to send along all
> his knowledge about the features of *every one of his* mechanisms
> implementations plus the requested features, or (as in my proposal)
> the initiator must adjust his mechanism preference list before sending
> it plus include the requested features.
No. The receiver implemenation knows what is availabale for each
proposed mechanism.
Sending that information along is not necessary.
> Sending along "trans_flag" and "prot_ready_flag" is not really useful, but
> I'd really like to have them available as (local) negotiation constraints!
This is out of context of SPNEGO.
Since the period of the last call is now closed, could John Linn attempt
to summarize the positions/options so that we can progress ?
Denis
> -Martin
--
Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from ietf.org by ietf.org id aa08910; 6 Jun 97 12:01 EDT
Received: from ietf.ietf.org by ietf.org id aa08653; 6 Jun 97 11:50 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-clark-telnet-control-03.txt
Date: Fri, 06 Jun 1997 11:50:21 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706061150.aa08653 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 : Telnet Comport Control Option
Author(s) : G. Clark
Filename : draft-clark-telnet-control-03.txt
Pages : 12
Date : 06/02/1997
This memo proposes a protocol to allow greater use of modems attached to a
network. Increased needs for "off network" communications has increased the
need for modems. Increasing the functionality of Telnet increases the
functionality of network attached modems. For example, the ability to send
a FAX via a network attached modem. This memo addresses configuration of
the comport to which the modem is attached. It does not address the
internal configuration of the modem 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-clark-telnet-control-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-clark-telnet-control-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-clark-telnet-control-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970602163401.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-clark-telnet-control-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-clark-telnet-control-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970602163401.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16631; 6 Jun 97 19:14 EDT
Received: from h-205-217-237-46.netscape.com by ietf.org id aa16536;
6 Jun 97 19:07 EDT
Received: from tintin.netscape.com (tintin.mcom.com [205.217.233.42])
by netscape.com (8.8.5/8.8.5) with ESMTP id QAA19148
for <ietf at ietf.org>; Fri, 6 Jun 1997 16:04:03 -0700 (PDT)
Received: from [207.1.144.171] by tintin.netscape.com
(Netscape Messaging Server 3.0) with SMTP id AAA11561
for <ietf at ietf.org>; Fri, 6 Jun 1997 16:04:03 -0700
Message-ID: <3398983F.5E1E213A at netscape.com>
Date: Fri, 06 Jun 1997 16:07:48 -0700
Sender:ietf-request at ietf.org
From: Kevin McEntee <kmcentee at netscape.com>
Reply-To: kmcentee at netscape.com
Organization: Netscape Inc
X-Mailer: Mozilla 4.0b6 (Macintosh; I; PPC)
MIME-Version: 1.0
To: "ietf at ietf.org" <ietf at ietf.org>
Subject: Working group and BOF agendas for Munich?
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
I just glanced at http://www.ietf.org/meetings/Munich.html and there is not
yet any info about working group or BOF agendas. Does have a place where I
can look for these?
- Kevin
Received: from cnri by ietf.org id aa16976; 6 Jun 97 19:50 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13630;
6 Jun 97 19:50 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <WAA04134 at pad-thai.cam.ov.com>; Fri, 6 Jun 1997 22:06:09 GMT
Date: Fri, 6 Jun 1997 15:05:44 -0700
From: Matt Bishop <bishop at cs.ucdavis.edu>
Message-Id: <199706062205.PAA09048 at nob>
To: cat-ietf at mit.edu
Subject: CFP: 1998 Symposium on Network and Distributed System Security
Precedence: bulk
CALL FOR PAPERS
The Internet Society Symposium on Network and Distributed System Security
Where: San Diego, California
When: March 1998
GOAL: The symposium will foster information exchange between hardware and
software developers of network and distributed system security services.
The intended audience is those who are interested in the practical aspects
of network and distributed system security, focusing on actual system
design and implementation, rather than theory. Encouraging and enabling
the Internet community to apply, deploy, and advance the state of available
security technology is the major focus of symposium. Symposium proceedings
will be published by the Internet Society. Topics for the symposium
include, but are not limited to, the following:
* Architectures for large-scale, heterogeneous distributed systems
* Security in malleable systems: mobile code, mobile agents, dynamic policy
updates, etc.
* Special problems: e.g. interplay between security goals and other goals --
efficiency, reliability, interoperability, resource sharing, and cost.
* Integrating security services with system and application security
facilities and with application protocols, including message handling,
file transport, remote file access, directories, time synchronization,
data base management, routing, voice and video multicast, network
management, boot services, and mobile computing.
* Fundamental services: authentication, integrity, confidentiality,
authorization, non-repudiation, and availability.
* Supporting mechanisms and APIs: key management and certification
infrastructures, audit, and intrusion detection.
* Telecommunications security, especially for emerging technologies -- very
large systems like the Internet, high-speed systems like the gigabit
testbeds, wireless systems, and personal communication systems.
* Controls: firewalls, packet filters, application gateways
* Object security and security objects
* Network information resources and tools such as World Wide Web (WWW),
Gopher, Archie, and WAIS.
* Electronic commerce: payment services, fee-for-access, EDI, notary;
endorsement, licensing, bonding, and other forms of assurance; intellectual
property protections
GENERAL CHAIR:
David Balenson, Trusted Information Systems
PROGRAM CHAIRS:
Matt Bishop, University of California at Davis
Steve Kent, BBN
PROGRAM COMMITTEE:
Steve Bellovin, AT&T Labs -- Research
Doug Engert, Argonne National Laboratories
Warwick Ford, VeriSign
Li Gong, JavaSoft
Rich Graveman, Bellcore
Ari Juels, RSA Laboratories
Tom Longstaff, CERT/CC
Doug Maughan, National Security Agency
Dan Nessett, 3Com Corporation
Rich Parker, NATO
Michael Roe, Cambridge University
Rob Rosenthal, DARPA
Wolfgang Schneider, GMD Darmstadt
Christoph Schuba, Purdue University
Win Treese, Open Market, Inc.
Jonathan Trostle, Novell
Gene Tsudik, USC/Information Sciences Institute
Steve Welke, Institute for Defense Analyses
LOCAL ARRANGEMENTS CHAIR:
Thomas Hutton, San Diego Supercomputer Center
PUBLICATIONS CHAIR:
Steve Welke, Institute for Defense Analyses
LOGISTICS CHAIR:
Torryn Brazell, Internet Society
SUBMISSIONS: The committee invites technical papers and panel
proposals, for topics of technical and general interest. Technical
papers should be 10-20 pages in length. Panel proposals should be two
pages and should describe the topic, identify the panel chair, explain
the format of the panel, and list three to four potential panelists.
Technical papers will appear in the proceedings. A description of each
panel will appear in the proceedings, and may at the discretion of the
panel chair, include written position statements from each panelist.
Each submission must contain a separate title page with the type of
submission (paper or panel), the title or topic, the names of the
author(s), organizational affiliation(s), telephone and FAX numbers,
postal addresses, Internet electronic mail addresses, and must list a
single point of contact if more than one author. The names of authors,
affiliations, and other identifying information should appear only on
the separate title page.
Submissions must be received by 1 August 1997, and should be made via
electronic mail in either PostScript or ASCII format. If the committee
is unable to print a PostScript submission, it will be returned and
hardcopy requested. Therefore, PostScript submissions should arrive
well before 1 August. If electronic submission is difficult,
submissions should be sent via postal mail.
All submissions and program related correspondence (only) should be
directed to the program chair: Matt Bishop, Department of Computer
Science, University of California at Davis, Davis CA 95616-8562,
Email: sndss98-submissions at cs.ucdavis.edu. Phone: +1 (916) 752-8060,
FAX: +1 (916) 752-4767,
Dates, final call for papers, advance program, and registration
information will be available at the URL:
http://www.isoc.org/conferences/ndss98.
Each submission will be acknowledged by e-mail. If acknowledgment is
not received within seven days, please contact the program chair as in-
dicated above. Authors and panelists will be notified of acceptance by
1 October 1997. Instructions for preparing camera-ready copy for the
proceedings will be sent at that time. The camera-ready copy must be
received by 1 November 1997.
Received: from ietf.org by ietf.org id aa17718; 7 Jun 97 23:15 EDT
Received: from [207.32.128.74] by ietf.org id aa12959; 7 Jun 97 22:55 EDT
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by unir.corp (8.7.3/8.7.3) with SMTP id VAA27981; Sat, 7 Jun 1997 21:40:43 -0500 (CDT)
Received: by webster.unety.net with Microsoft Mail
id <01BC738C.7A4E51A0 at webster.unety.net>; Sat, 7 Jun 1997 21:48:04 -0500
Message-ID: <01BC738C.7A4E51A0 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Cc: "'newdom at ar.com'" <newdom at ar.com>
Subject: ITU/ISOC/IETF
Date: Sat, 7 Jun 1997 21:48:02 -0500
Encoding: 23 TEXT
Source-Info: From (or Sender) name not authenticated.
Is the IETF really a member of the ITU ?
@@@@ http://aska.glocom.ac.jp/resa/APPLe/B-Shaw.html
Robert Shaw, International Telecommunication Union (ITU),
APPLe Workshop, Montreal, 28 June 1996
"In fact, one could even say that the IETF is a member
of the ITU because ISOC is sort of the parent body of the
IETF, and ISOC is a member -- the Internet Society is a
member of the ITU also -- or a member of the telecommunication
standardization sector."
@@@@@@@@@@@@@@@@@@@@@@@@@@@@
--
Jim Fleming
Unir Corporation
http://www.Unir.Corp
Received: from ietf.org by ietf.org id aa19704; 8 Jun 97 2:30 EDT
Received: from email.archlab.tuwien.ac.at by ietf.org id aa19610;
8 Jun 97 2:24 EDT
Received: by email.archlab.tuwien.ac.at (950413.SGI.8.6.12/940406.SGI.AUTO)
id IAA08066; Sun, 8 Jun 1997 08:19:54 +0200
Date: Sun, 8 Jun 1997 08:19:54 +0200 (MDT)
Sender:ietf-request at ietf.org
From: Sascha Ignjatovic <signato at email.archlab.tuwien.ac.at>
To: Jim Fleming <JimFleming at unety.net>
cc: "'ietf at ietf.org'" <ietf at ietf.org>, "'newdom at ar.com'" <newdom at ar.com>,
robert.shaw at itu.int, vcerf at mci.net, heat at isoc.org
Subject: Re: ITU/ISOC/IETF
In-Reply-To: <01BC738C.7A4E51A0 at webster.unety.net>
Message-ID: <Pine.SGI.3.91.970608081352.8057A-100000 at email.archlab.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
it will be great if the ietf isoc and itu cooperate for the benefit of future
internet development
this cooperation is a natural nechst step in further globalisation of the
internet
thanks
sasha
On Sat, 7 Jun 1997, Jim Fleming wrote:
>
> Is the IETF really a member of the ITU ?
>
>
> @@@@ http://aska.glocom.ac.jp/resa/APPLe/B-Shaw.html
>
> Robert Shaw, International Telecommunication Union (ITU),
> APPLe Workshop, Montreal, 28 June 1996
>
> "In fact, one could even say that the IETF is a member
> of the ITU because ISOC is sort of the parent body of the
> IETF, and ISOC is a member -- the Internet Society is a
> member of the ITU also -- or a member of the telecommunication
> standardization sector."
>
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@
>
> --
> Jim Fleming
> Unir Corporation
> http://www.Unir.Corp
>
>
>
Received: from ietf.org by ietf.org id aa19809; 8 Jun 97 2:37 EDT
Received: from bbs.ctonline.it by ietf.org id aa19747; 8 Jun 97 2:34 EDT
X-ROUTED: Sun, 8 Jun 1997 08:28:18 +0100
X-TCP-IDENTITY: Fabio Camarda
Received: from lupin.ctonline.it [151.99.143.136] by ctonline.it with smtp
id AIBLCIBD ; Sun, 8 Jun 1997 08:27:40 +0100
Sender:ietf-request at ietf.org
From: Massimo Camarda <lupin at ctonline.it>
To: ietf at ietf.org
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject:
Date: Sat, 7 Jun 1997 19:15:52 +0200
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1157
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <9706080234.aa19747 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
I want to join the mailing list
Received: from ietf.org by ietf.org id aa01067; 8 Jun 97 3:40 EDT
Received: from cnri by ietf.org id aa20140; 8 Jun 97 3:05 EDT
Received: from ns.ibo.ch by CNRI.Reston.VA.US id aa02219; 8 Jun 97 3:05 EDT
Received: from cgchm.is.chbs by gatekeeper.chbs.ciba.com; (5.65v3.2/1.1.8.2/12Mar96-0208PM)
id AA27339; Sun, 8 Jun 1997 09:01:14 +0200
Received: from mta1.is.chbs by Central.CHBS.CIBA.COM
id AA00749; Sun, 8 Jun 1997 09:00:46 +0200 (5.65c8/Ciba2.0-C1.1)
Received: by mta1.is.chbs (5.65v3.2/DEC-Ultrix/4.3)
id AA24948; Sun, 8 Jun 1997 08:58:44 +0200
X400-Received: by /PRMD=CIBA/ADMD=attmail/C=CH/;
converted ((1) (0) (10021) (7) (1) (0) (1), (1) (0) (10021) (7) (1) (0) (6));
Relayed; 8 Jun 1997 08:59:00 +0200
X400-Received: by mta chbs-mta1 in /PRMD=ciba/ADMD=attmail/C=ch/;
converted ((1) (0) (10021) (7) (1) (0) (1), (1) (0) (10021) (7) (1) (0) (6));
Relayed; 8 Jun 1997 06:58:43 +0000
X400-Received: by mta IS_EXC01_CHBS in /PRMD=CIBA/ADMD=attmail/C=CH/;
Relayed; 8 Jun 1997 09:01:41 +0200
X400-Received: by mta IS_EXC07_CHBS in /PRMD=CIBA/ADMD=attmail/C=CH/;
Relayed; 8 Jun 1997 09:01:30 +0200
X400-Received: by mta NOVARTIS/CHBSIS01R in /PRMD=CIBA/ADMD=attmail/C=CH/;
Relayed; 8 Jun 1997 09:01:30 +0200
Date: 8 Jun 1997 09:01:30 +0200
X400-Originator: /DD.MS=CIBADELAAD$/DECGLA10$/SCHAAWO1/@mhs.ciba.com
X400-Mts-Identifier: [/PRMD=CIBA/ADMD=attmail/C=CH/;NOVARTIS/CHBSIS01R/0012621E]
Sender:ietf-request at ietf.org
From: Schaaf Wolfgang MSM AD DE </DD.MSXENCAP=MS/DD.MS=CIBADELAAD$/DECGLA10$/SCHAAWO1 at mhs.ciba.com>
To: Wolfgang <ietf at CNRI.Reston.VA.US>
Subject: Test
Importance: normal
Autoforwarded: FALSE
Message-Id: <"/GUID:48712C05*"@MHS>
Original-Encoded-Information-Types: (2) (6) (3) (4) (11)
X400-Content-Type: P2-1988 (22)
Priority: normal
Source-Info: From (or Sender) name not authenticated.
Test 08.06.1997 08:37.
Received: from ietf.org by ietf.org id aa09711; 8 Jun 97 19:11 EDT
Received: from hiway1.exit109.com by ietf.org id aa09605; 8 Jun 97 19:04 EDT
Received: from ppp6-rb.exit109.com (ppp6-rb.exit109.com [205.164.176.133]) by hiway1.exit109.com (8.8.5/8.7.3) with SMTP id TAA17025; Sun, 8 Jun 1997 19:00:37 -0400 (EDT)
Received: by ppp6-rb.exit109.com with Microsoft Mail
id <01BC743E.337C26A0 at ppp6-rb.exit109.com>; Sun, 8 Jun 1997 19:00:16 -0400
Message-ID: <01BC743E.337C26A0 at ppp6-rb.exit109.com>
Sender:ietf-request at ietf.org
From: "Herman R. Silbiger" <hsilbiger at exit109.com>
To: "'ietf at ietf.org'" <ietf at ietf.org>, 'Jim Fleming' <JimFleming at unety.net>
Cc: "'newdom at ar.com'" <newdom at ar.com>
Subject: RE: ITU/ISOC/IETF
Date: Sun, 8 Jun 1997 13:49:26 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Source-Info: From (or Sender) name not authenticated.
ISOC is a member of the Telecommunication Standardization Sector of the =
ITU. ISOC can therefore delegate its members to attend ITU-T meetings =
and offer technical contributions. To attend a particular meeting a =
communication should be sent from ISOC management designating the =
individuals who will be attending a particular meeting representing =
ISOC. I personally have never seen anyone with an ISOC badge at a =
meeting, nor have I seen any ISOC contributions.
Disclaimer: The above is my interpretation of the situation. I am sure =
that the ITU-T secretariat can clarify the situation.
Herman Silbiger
Etc., etc.
----------
From: Jim Fleming[SMTP:JimFleming at unety.net]
Sent: Saturday, June 07, 1997 10:48 PM
To: 'ietf at ietf.org'
Cc: 'newdom at ar.com'
Subject: ITU/ISOC/IETF
Is the IETF really a member of the ITU ?
@@@@ http://aska.glocom.ac.jp/resa/APPLe/B-Shaw.html
Robert Shaw, International Telecommunication Union (ITU),
APPLe Workshop, Montreal, 28 June 1996
"In fact, one could even say that the IETF is a member
of the ITU because ISOC is sort of the parent body of the
IETF, and ISOC is a member -- the Internet Society is a
member of the ITU also -- or a member of the telecommunication
standardization sector."
@@@@@@@@@@@@@@@@@@@@@@@@@@@@
--
Jim Fleming
Unir Corporation
http://www.Unir.Corp
Received: from ietf.org by ietf.org id aa10270; 8 Jun 97 20:12 EDT
Received: from email.archlab.tuwien.ac.at by ietf.org id aa10197;
8 Jun 97 20:08 EDT
Received: by email.archlab.tuwien.ac.at (950413.SGI.8.6.12/940406.SGI.AUTO)
id CAA09998; Mon, 9 Jun 1997 02:04:26 +0200
Date: Mon, 9 Jun 1997 02:04:25 +0200 (MDT)
Sender:ietf-request at ietf.org
From: Sascha Ignjatovic <signato at email.archlab.tuwien.ac.at>
To: "Herman R. Silbiger" <hsilbiger at exit109.com>
cc: "'ietf at ietf.org'" <ietf at ietf.org>, 'Jim Fleming' <JimFleming at unety.net>,
"'newdom at ar.com'" <newdom at ar.com>
Subject: RE: ITU/ISOC/IETF
In-Reply-To: <01BC743E.337C26A0 at ppp6-rb.exit109.com>
Message-ID: <Pine.SGI.3.91.970609011423.9850A-100000 at email.archlab.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sun, 8 Jun 1997, Herman R. Silbiger wrote:
> ISOC is a member of the Telecommunication Standardization Sector of the ITU.
ISOC can therefore delegate its members to attend ITU-T meetings and offer
technical contributions. To attend a particular meeting a
communication should be sent from ISOC management designating the
individuals who will be attending a particular meeting representing
ISOC. I personally have never seen anyone with an ISOC badge at a
meeting, nor have I seen any ISOC contributions.
>
> Disclaimer: The above is my interpretation of the situation.
I am sure that the ITU-T secretariat can clarify the situation.
>
> Herman Silbiger
> Etc., etc.
> ----------
>
> Robert Shaw, International Telecommunication Union (ITU),
mr shaw hase worked so hard last times for the iahc-gtld-core-mou
that he hase taken 3 weeks vacation starting with this sunday
so he will not be able to comment on this until he is back
but mr.dave crocker- a hard-core ietf man hase worked very well
with the people/man from the itu and i think they have done a very good
job and the itu man hase made a essential contribution
so i see nothing bad in posible cooperation between isoc/ietf/itu
mr.pekka tarayane sekretary general of the itu hase spocken in his
plenary lecture befor the gtld-mou meeting in geneva about
"historic event occuring when the internet and telecomm world comming
together" represented by the isoc and itu
> "In fact, one could even say that the IETF is a member
> of the ITU because ISOC is sort of the parent body of the
> IETF, and ISOC is a member -- the Internet Society is a
> member of the ITU also -- or a member of the telecommunication
> standardization sector."
there is no doubt that the ietf hase always have and will always remain the
"technologie competence and autority for the internet" and that the
telecomm world hase to accept the internet and to learn from it and to
contribute to it
so i see a very bright future for internet when internet community and
the telecomm community come together and unite their forces to build up
a planetary information infrastructure on internet basis
thanks
sasha
ps.in my understanding there was strategic reason for establishing
contacts between the internet community and the so callt telecomm community
and to the architects of this i would like to offer my humble respect
and many thanks
pps.i am also sory and wondering a little that the ietf community is not
so "actively" participating in the isoc/iana/iahc/..gtld project/discussion
with the signing of the gtld-mou you/your organisation will so becom a
member of the gtld policy advisory body and be more active contributor to
the public owned internet generic domain name system
http://www.gtld-mou.org
i am shure that there are many persons within the ietf familiar with
recent developments in this area but for those who are not please
contribute to the internet selfgovernance by beeing a part of it
disclamair:i am a enthusiastic privat person and do not speack for any
organisation
and i am bag the ietf audiance for forgivnes if i am som how writing
samthing wrong becouse i am not a technician but a monck
Received: from ietf.org by ietf.org id aa06949; 9 Jun 97 10:21 EDT
Received: from ietf.ietf.org by ietf.org id aa05913; 9 Jun 97 9:51 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: dhcp-v4 at bucknell.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dhc-agent-options-01.txt
Date: Mon, 09 Jun 1997 09:51:57 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706090951.aa05913 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Dynamic Host Configuration
Working Group of the IETF.
Title : DHCP Relay Agent Information Option
Author(s) : M. Patrick
Filename : draft-ietf-dhc-agent-options-01.txt
Pages : 11
Date : 06/06/1997
Newer high-speed public Internet access technologies call for a high-speed
modem to have a LAN attachment to one or more user hosts. It is
advantageous to use DHCP to assign user host IP addresses in this
environment, but a number of security and scaling problems arise with such
"public" DHCP use. This draft calls for the definition of a "DHCP Relay
Agent Information" option that is appended to a DHCP packet forwarded from
a client to a server by a relay agent. The Server may or may not use the
information in the the Relay Agent Information option; in either case, it
echoes back the option verbatim in server-to-client replies.
The "Relay Agent Information" option contains sub-options that convey
information known by the relay agent. The initial sub-options are defined
for a relay agent that is co-located in a public circuit access unit.
These include a "circuit ID" for the incoming circuit and a "remote ID"
which provides a trusted identifier for the remote high-speed modem.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-agent-options-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-agent-options-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dhc-agent-options-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970606164755.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-agent-options-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-agent-options-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970606164755.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06939; 9 Jun 97 10:21 EDT
Received: from ietf.ietf.org by ietf.org id aa05874; 9 Jun 97 9:51 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-ldapv3-protocol-05.txt
Date: Mon, 09 Jun 1997 09:51:36 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706090951.aa05874 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : Lightweight Directory Access Protocol (v3)
Author(s) : M. Wahl, T. Howes, S. Kille
Filename : draft-ietf-asid-ldapv3-protocol-05.txt
Pages : 42
Date : 06/06/1997
The protocol described in this document is designed to provide access to
directories supporting the X.500 models, while not incurring the resource
requirements of the X.500 Directory Access Protocol (DAP). This protocol is
specifically targeted at management applications and browser applications
that provide read/write interactive access to directories. When used with a
directory supporting the X.500 protocols, it is intended to be a complement
to the X.500 DAP.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-asid-ldapv3-protocol-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3-protocol-05.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-ldapv3-protocol-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970606153808.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldapv3-protocol-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldapv3-protocol-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970606153808.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06936; 9 Jun 97 10:21 EDT
Received: from ietf.ietf.org by ietf.org id aa05784; 9 Jun 97 9:51 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-ids at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ids-iwps-schema-spec-06.txt
Date: Mon, 09 Jun 1997 09:51:05 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706090951.aa05784 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integrated Directory
Services Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : A Common Schema for the Internet White Pages Service
Author(s) : T. Genovese, B. Jennings
Filename : draft-ietf-ids-iwps-schema-spec-06.txt
Pages : 6
Date : 06/06/1997
This work is the result of the IETF Integrated Directory Services (IDS)
Working Group. The IDS Working Group proposes a standard specification for
a simple Internet White Pages service by defining a common schema for use
by the various White Pages servers. This schema is independent of specific
implementations of the White Pages service.
This document specifies the minimum set of core attributes of a White Pages
entry for an individual and describes how new objects with those attributes
can be defined and published. It does not describe how to represent other
objects in the White Pages service. Further, it does not address the
search sort expectations within a particular service.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ids-iwps-schema-spec-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ids-iwps-schema-spec-06.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ids-iwps-schema-spec-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
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: <19970606150105.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ids-iwps-schema-spec-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ids-iwps-schema-spec-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970606150105.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06923; 9 Jun 97 10:21 EDT
Received: from ietf.ietf.org by ietf.org id aa05856; 9 Jun 97 9:51 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-ldapv3-tls-01.txt
Date: Mon, 09 Jun 1997 09:51:31 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706090951.aa05856 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : Lightweight Directory Access Protocol (v3):
Extension for Transport Layer Security
Author(s) : J. Hodges, B. Morgan, M. Wahl
Filename : draft-ietf-asid-ldapv3-tls-01.txt
Pages : 7
Date : 06/06/1997
This document defines the "Start Transport Layer Security (TLS)
Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS
establishment in an LDAP association and is defined in terms of an LDAP
extended request.
The key words "MUST", "SHOULD", and "MAY" used in this document are to be
interpreted as described in [Bradner97].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-asid-ldapv3-tls-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3-tls-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-ldapv3-tls-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970606153419.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldapv3-tls-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldapv3-tls-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970606153419.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06935; 9 Jun 97 10:21 EDT
Received: from ietf.ietf.org by ietf.org id aa05730; 9 Jun 97 9:50 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: oncrpc-wg at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-oncrpc-rpcsec_gss-05.txt
Date: Mon, 09 Jun 1997 09:50:45 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706090950.aa05730 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 ONC Remote Procedure Call
Working Group of the IETF.
Title : RPCSEC_GSS Protocol Specification
Author(s) : M. Eisler, A. Chiu, L. Ling
Filename : draft-ietf-oncrpc-rpcsec_gss-05.txt
Pages : 22
Date : 06/06/1997
This memo describes an ONC/RPC security flavor that allows RPC protocols to
access the Generic Security Services Application Programming Interface
(referred to henceforth as GSS-API).
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-oncrpc-rpcsec_gss-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-oncrpc-rpcsec_gss-05.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-oncrpc-rpcsec_gss-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970606110241.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-oncrpc-rpcsec_gss-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-oncrpc-rpcsec_gss-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970606110241.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06950; 9 Jun 97 10:21 EDT
Received: from ietf.ietf.org by ietf.org id aa05821; 9 Jun 97 9:51 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: srvloc at corp.home.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-svrloc-advertising-02.txt
Date: Mon, 09 Jun 1997 09:51:14 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706090951.aa05821 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 Service Location Protocol
Working Group of the IETF.
Title : Advertising Services (Providing information to support
service discovery)
Author(s) : R. Moats, M. Hamilton
Filename : draft-ietf-svrloc-advertising-02.txt
Pages : 11
Date : 06/06/1997
This document proposes a solution to the problem of finding information
about that services are being offered at a particular Internet domain,
based on deployment experience with the Netfind White Pages directory
software.
This approach makes it possible to supply clients with more information
than the DNS aliases that have been widely deployed in this role - notably
the port numbers being used by servers. However, it is not without
problems, and we have tried to take account of these.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-svrloc-advertising-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-advertising-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-svrloc-advertising-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970606114258.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-svrloc-advertising-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-svrloc-advertising-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970606114258.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06947; 9 Jun 97 10:21 EDT
Received: from ietf.ietf.org by ietf.org id aa05803; 9 Jun 97 9:51 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-katsube-interop-between-lsps-00.txt
Date: Mon, 09 Jun 1997 09:51:11 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706090951.aa05803 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Interoperation Between Distinct Types of
Label Switched Paths
Author(s) : Y. Katsube, H. Esaki
Filename : draft-katsube-interop-between-lsps-00.txt
Pages : 9
Date : 06/06/1997
Label Switching Routers are able to handle several distinct types of Label
Switched Paths (LSPs) depending on the triggers for establishing or
releasing LSPs or the granularity of the flow that are dedicated to each of
the LSPs. This memo first analyzes characteristics of individual types of
LSPs, and discusses possible interoperation scenario between them.
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-katsube-interop-between-lsps-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-katsube-interop-between-lsps-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-katsube-interop-between-lsps-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970606113721.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-katsube-interop-between-lsps-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-katsube-interop-between-lsps-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970606113721.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06920; 9 Jun 97 10:21 EDT
Received: from ietf.ietf.org by ietf.org id aa05766; 9 Jun 97 9:51 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: srvloc at corp.home.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-svrloc-service-scheme-01.txt
Date: Mon, 09 Jun 1997 09:51:01 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706090951.aa05766 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 Service Location Protocol
Working Group of the IETF.
Title : Service Templates and service: Schemes
Author(s) : E. Guttman, C. Perkins
Filename : draft-ietf-svrloc-service-scheme-01.txt
Pages : 22
Date : 06/06/1997
Service: schemes define URLs (called "service: URLs" in this document)
which are primarily intended to be used by the Service Location Protocol in
order to distribute service access information. These schemes provide an
extensible framework for client based network software to obtain
configuration information required to make use of network services.
When registering a service: URL with a Directory Agent, the URL may be
accompanied by a set of well defined attributes which define the
charateristics of the service. These attributes may convey
configuration information to client software, or
service characteristics meaningful to end users.
This document describes how to define and standardize new service types
and attributes for use with the service: scheme using Service Templates.
These templates are human and machine readable. They may be used by
administrative tools to parse service registration information and
by client applications to provide localized translations of service
attribute strings.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-svrloc-service-scheme-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-service-scheme-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-svrloc-service-scheme-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970606111156.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-svrloc-service-scheme-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-svrloc-service-scheme-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970606111156.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06933; 9 Jun 97 10:21 EDT
Received: from ietf.ietf.org by ietf.org id aa05949; 9 Jun 97 9:52 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-macker-mdp-framework-02.txt
Date: Mon, 09 Jun 1997 09:52:03 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706090952.aa05949 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The Multicast Dissemination Protocol (MDP) Framework
Author(s) : J. Macker, W. Dang
Filename : draft-macker-mdp-framework-02.txt
Pages : 14
Date : 06/06/1997
This document outlines a simple protocol framework for reliable multicast
dissemination of data files. The general framework was originally developed
and used by the Image Multicaster (IMM) application within the Internet
MBone for dissemination of satellite imagery. This document describes the
more general use of the protocol framework as a reliable bulk file transfer
technique. We discuss the present operational modes, some performance
issues, and the basic application data units (ADUs) used. This is not
intended to be a detailed protocol specification document, but rather a
broad description of the basic protocol features and a discussion of
issues. Further detailed description of the protocol implementation may be
provided in future documents.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-macker-mdp-framework-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-macker-mdp-framework-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-macker-mdp-framework-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970606165303.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-macker-mdp-framework-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-macker-mdp-framework-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970606165303.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07331; 9 Jun 97 10:33 EDT
Received: from ietf.ietf.org by ietf.org id aa05842; 9 Jun 97 9:51 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-ldapv3-lang-02.txt
Date: Mon, 09 Jun 1997 09:51:22 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706090951.aa05842 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : Use of Language Codes in LDAPv3
Author(s) : M. Wahl, T. Howes
Filename : draft-ietf-asid-ldapv3-lang-02.txt
Pages : 8
Date : 06/06/1997
The Lightweight Directory Access Protocol [1] provides a means for clients
to interrogate and modify information stored in a distributed directory
system. The information in the directory is maintained as attributes [2]
of entries. Most of these attributes have syntaxes which are
human-readable strings, and it is desirable to be able to indicate the
natural language associated with attribute values.
This document describes how language codes [3] are carried in LDAP and are
to be interpreted by LDAP servers. All implementations MUST be prepared to
accept language codes in the LDAP protocols. Servers may or may not be
capable of storing attributes with language codes in the directory.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-asid-ldapv3-lang-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3-lang-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-ldapv3-lang-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970606152928.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldapv3-lang-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldapv3-lang-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970606152928.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa11714; 9 Jun 97 13:31 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09193;
9 Jun 97 13:31 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <PAA02998 at pad-thai.cam.ov.com>; Mon, 9 Jun 1997 15:06:25 GMT
Message-Id: <199706091506.LAA25070 at gza-client1.cam.ov.com>
To: D.Pinkas at frcl.bull.fr
Cc: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Snego & GSS V2
In-Reply-To: Your message of "Fri, 06 Jun 1997 13:04:46 PDT."
<33986D5E.724D at frcl.bull.fr>
Date: Mon, 09 Jun 1997 11:06:12 -0400
From: John Linn <linn at cam.ov.com>
Precedence: bulk
CAT/Negotiation fanciers:
In his message of 6 June, Denis Pinkas asked that I attempt to
summarize the posted positions and options vis-a-vis snego-05 in the
interests of progress. Here's an attempt; if I've captured any
positions incorrectly, clarifications are hereby requested. Further,
comments on positions from others who have reviewed the discussion
would be appreciated.
ISSUE #1: Per GSS-V2/RFC-2078, there is no facility to determine in
advance of context establishment whether or not confidentiality and
integrity services will be available on a context, and no facility for
callers to indicate request/requirement for these services. Addition
of such a facility would be particularly useful in negotiated
mechanism environments.
Recognizing these factors, three choices have been presented:
(1A) Retain current GSS-V2 behavior. (Suggested by Denis Pinkas.)
(1B) Modify GSS-V2, by added parameters to gss_init_sec_context() or
by additional calls, to allow indication of requests or requirements
for per-message integrity and confidentiality services; this can be
further subdivided into:
(1B-1) Provide advisory facilities, to request the services if
available, but not to prevent context establishment if unavailable.
(Suggested by Martin Rex and Mike Swift.)
(1B-2) Provide directive facilities, in response to which no context
would be established if the directed facilities were unavailable.
(1B-3) Provide both (1B-1) and (1B-2). (Suggested by Martin Rex, 21
May.)
(1C) Add new facilities in conjunction with the negotiation facility,
but do not modify base GSS-V2. (Suggested by Martin Rex, strongly
endorsed by him on 5 June; comparable facilities currently being
applied by Mike Swift)
Notes: Availability of services cannot be determined statically based
on a mechanism identifier, but may instead be target-dependent. All
choices except (1A) are assumed to require new indicator elements
within the negotiation protocol's ContextFlags.
ISSUE #2: If any of choices (1B) are to be undertaken, should this be
accomplished:
(2-1) via new calls? (Proposal made by Martin Rex, 28 May. Denis
Pinkas comments, 29 May, that no changes should be made to
gss_init_sec_context(); John Linn concurs, 2 June, and concurrently
raises unresponded sub-issue about suitability of adding new calls to
RFC-2078bis. Backward compatibility for gss_init_sec_context() also
endorsed by Martin Rex, 5 June.)
(2-2) via extensions to gss_init_sec_context()?
Aside: It now strikes me that it might be possible to support a form
of (1B-1), but not (1B-2), in a backward-compatible fashion, by
adopting currently-unused bits and applying the following semantics:
if a caller were to set the "integrity" or "confidentiality" bit, this
would indicate that the service was *not* desired; existing callers
would default to requests for both services.
ISSUE #3: Should trans_flag and prot_ready_flag be specifiable locally
as negotiation constraints, even though indicators for these
facilities need not traverse the protocol? Martin Rex requested this;
Denis Pinkas considered it out of scope.
ISSUE #4: Should the snego document define the policy which is used to
select among alternate negotiable mechanisms? Denis Pinkas believes
so, and considers that this may be necessary in order to achieve
interoperability. Mike Swift argued that it should not be specified
within the document.
ISSUE #5: Should snego incorporate facilities for restarting context
establishment with a second mechanism if an initial mechanism-level
context establishment fails or yields unacceptable results? Requires
(1B-2). (Marc Horowitz suggested; Martin Rex commented that it would
be useful but would add complexity and, possibly, overhead.)
ISSUE #6: Should it be acceptable for local implementations to modify
the caller's set of requests before including the results in
negotiated protocol elements? John Linn suggested; Denis Pinkas
accepted.
--jl
Received: from cnri by ietf.org id aa13014; 9 Jun 97 14:13 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09775;
9 Jun 97 14:13 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <QAA09416 at pad-thai.cam.ov.com>; Mon, 9 Jun 1997 16:11:46 GMT
Message-Id: <199706091610.AA17508 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: Snego & GSS V2
To: cat-ietf at mit.edu
Date: Mon, 9 Jun 1997 17:47:27 +0200 (MESZ)
Cc: D.Pinkas at frcl.bull.fr
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Linn wrote:
>
> Denis writes:
>
> > Note : If we enrich, for backward compatibility, GSS_init_sec_context
> > should be kept unchanged and thus it would make sense to have new APIs.
>
> I agree. One question, though: on p. 7 of snego-05, it's stated that
> "The context flags should be filled in from the req_flags parameter of
> init_sec_context()." Is it necessarily required that the req_flags inputs
> will always be copied precisely into the emitted token, or is it acceptable
> for lower implementation layers within the client system to filter or
> modify the client requests?
>
> >
> > I would favor two additional APIs, independent from GSS_Get_neg_mechs
> > and GSS_Set_neg_mechs that would allow to specify the flags and make it
> > part of GSS-API V2+ so that the functionality becomes available whether
> > a precise mech is specified or the negotiation mechanism is specified.
>
> This seems like a reasonable result, but would represent the first
> post-2078 example of adding new calls to the GSS-API definition.
> What do people think about taking such a step at this time?
I'm sorry for my typo about context establishment failures.
I wasn't looking for a way to make context establishment fail in the
absence of some of the "requested" features. I was only looking for
a possibility for an application to indicate "need badly" and
"nice-to-have" features in the presence of a negotiation mechanism,
which should consider the "need badly" features in the negotiation
process. Therefore I think it is a PNEGO issue only, and shouldn't
affect the base GSS-API v2 spec at all.
I mean what is the reason that an application might want to influence
the negotiation process at all, why shouldn't it just accept whatever
mechanism there it ends up with (completely ignoring how it is selected).
Maybe because it isn't very comfortable with the (missing) features of
the resulting security context. A "context feature" would be a portable
negotiation constraint, Mechanism OIDs definitely aren't.
I really like the portability idea in GSS-API; please don't victimize
the portability guideline in the negotiation mechanism.
-Martin
Received: from cnri by ietf.org id aa14254; 9 Jun 97 15:00 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10421;
9 Jun 97 15:00 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <PAA05096 at pad-thai.cam.ov.com>; Mon, 9 Jun 1997 15:28:15 GMT
Message-Id: <199706091526.AA12677 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: Snego & GSS V2
To: D.Pinkas at frcl.bull.fr
Date: Mon, 9 Jun 1997 11:26:23 -0400 (EDT)
Cc: cat-ietf at mit.edu
In-Reply-To: <33986D5E.724D at frcl.bull.fr> from "Denis Pinkas" at Jun 6, 97 01:04:46 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Denis Pinkas wrote:
>
> Martin Rex wrote:
> >
> > The original request from Mike Swift was to have feature requirements
> > being considered for SELECTION of the best common mechanism, but to
> > still establish a security context even when the feature "requirements"
> > cannot be met.
> >
> > If the requirements are to affect the *negotiation*, they have to part
> > of SPNEGO, not base GSS-API.
> >
> > In one of my last mails I had a bad typo.
> > I wrote:
> > > ... the negotiation constraints should be transferred seperately
> > > from the feature request of gss_init_sec_context().
> > > But even negotiation constraining feature requests should
> > > prevent a successful context establishment without these features.
> > |
> > +---- insert 'NOT'
>
>
> This makes a BIG difference ! I wonder what is the opinion from the
> other members from the group.
>
> This is what we have today and thus I do not see a reason for a change.
The currently proposed SPNEGO only allows to specify a mechanism
preference list. There is no way for an application to have the
mechanism preference list to be reordered to match the feature
profile desired by the application. The only way for an application
to do that with current SPNEGO is for the application to somehow
learn about the features of the installed mechanisms and create/adjust
the mechanism preference list accordingly.
This stuff should rather be done once within SPNEGO instead of doing
it over and over again in each and every application.
>
> > I think it's perfectly fine to end up with a security context, even when
> > the features that I wanted to be considered for the *negotiation* can
> > not be met.
>
> This feature is in the original spec. It is not really clear what you
> are asking for.
Being able to direct the negotiation out of a portable application
without having to know about (1) the mechanism requirements and
(2) the specific features of the installed implementation of a
gssapi mechanism.
>
> > It would be much easier (and "portable") for an application to
> > do a sensible negotiation by indicating prefererred features than
> > by creating a list of mechanisms with an order of preference.
> >
> > An application should neither have to know or have to guess about
> > features or "quality" of the mechanisms that are currently installed,
> > because that is not really portable. If an application is concerned
> > about security aspects, it will first of all distinguish "unprotected",
> > "integrity-protected" and "confidentiality-protected".
> > A mechanism preference list should be created/maintained by the sysadmin/user
> > who installs the mechanisms. Features availablility from a mechanism
> > should either remain an (=non-standard) SPNEGO-configuration issue,
> > or be made inquire-able in base GSS-API (=standard).
>
> Features availablility are not static and are target dependent.
> Any way, IMHO, this question is independent from SPNEGO.
Potential availability of a feature *IS* static -- it is either
a implementation or configuration characteristic. If there turn out
to be many context/target-derived features restrictions due to any
kind of (political) reasons, then fallback negotiation cycles as
proposed by Marc Horowitz would be a solution. I very much doubt
that there will context/target derived feature restrictions on
anonymity, prot-ready, context-export, replay- and sequence-detection --
still I would appreciate if these features were available to constrain
the negotiation!
The question is not independent from SPNEGO. SPNEGO has complete control
over the negotiation process and any policies that you want to put in there.
The current set of parameters available to an application to influence
the negotiation to match its desires is small, and it cannot be
precompiled/preconfigured into any application as it is.
If the application doesn't like the result of SPNEGO, then it can start
doing it's own (unprotected) negotiation dealing with the Mech-OIDs and
its knowledge about the mechanisms features (that it currently needs
to feed SPNEGO). Before the protection was introduced into SPNEGO,
there was *no added value* in SNEGO.
>
> > The availability of some features may well be implementation specific
> > (versus mech-specific or context-related). This is especially obvious
> > for the features "trans_flag" and "prot_ready_flag" (which no-one
> > commented on -- I listed them in my proposal). Each side of the
> > connection will (at most/only) know about features of the locally
> > installed mechanism implementation! To be able for the context acceptor
> > to make a sensible decision, the initiator either has to send along all
> > his knowledge about the features of *every one of his* mechanisms
> > implementations plus the requested features, or (as in my proposal)
> > the initiator must adjust his mechanism preference list before sending
> > it plus include the requested features.
>
> No. The receiver implemenation knows what is availabale for each
> proposed mechanism.
> Sending that information along is not necessary.
Which implementation? GSS-API mechanism or SNEGO or application?
Neither can possible have a priori knowledge about the features of
the implementation at the other end, except maybe the "required"
features from each individual gss-api mechanism spec. The "required"
feature list may be rather small. We already have a lot of
optional features in gssapi v2 and base mechanisms specs.
>
>
> > Sending along "trans_flag" and "prot_ready_flag" is not really useful, but
> > I'd really like to have them available as (local) negotiation constraints!
>
> This is out of context of SPNEGO.
I violently disagree. ;-)
The purpose of negotiation is to find the best suitable common mechanism
for two communication party. The negotiation should be configurable
for policy (general availability/unavailability of a mechanism is good
enough) and configurable for application requirements on the quality
of protection.
>
> Since the period of the last call is now closed, could John Linn attempt
> to summarize the positions/options so that we can progress ?
If the working group feels that the document is mature enough
to become the one-and-only negotiation mechanism already, then I
won't interfere.
I would really appreciate if (potential) spnego implememtors as well as
(potential) application programmers would comment if they feel the
current spec is sufficient.
My personal opinion is that I don't currently see any added value
in spnego besides the protection of the negotiation. Currently I have
implemented support for some very simple (and unprotected) negotiation
within my application layer protocol, and I have a precompiled list of
mechanism features that the application uses to "guess" what protection
will be available when an arbitrary gssapi mechanism is loaded and
"analyzed" via gss_indicate_mechs(). Two things that could simplify
my code: (1) potential availability of features can by dynamically
queried -- a base-GSS-API issue, and (2) availability of features
can be used to constrain a PNEGO mechanism negotiation.
-Martin
Received: from ietf.org by ietf.org id aa15009; 9 Jun 97 15:38 EDT
Received: from njau.nj.mt.np.els-gms.att.net by ietf.org id aa14891;
9 Jun 97 15:32 EDT
Date: Mon, 09 Jun 1997 10:07:55 -0500
Sender:ietf-request at ietf.org
From: Vito Peter Jokubaitis <vjokubaitis at attmail.com>
Received: from vjokubaitis by attmail; Mon Jun 9 19:25:10 GMT 1997
Phone: +1 908 580 4283
Fax-Phone: +1 908 580 6881
Subject: RE: ITU/ISOC/IETF
To: ietf at ietf.org, JimFleming at unety.net, hsilbiger at exit109.com
Cc: newdom at ar.com
X-MAPI-Message-ID: 00000000F86993E0F444CF11A85400AA0059C232C47B3100
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-ID: <AW300MP000-vjokubaitis-46>
Source-Info: From (or Sender) name not authenticated.
Herman's right=21
ISOC is NOT a member of the ITU. Membership in the ITU is restricted to =
governments. ISOC joined the Sectors (Telecommunications, Radiocommunica=
tions, Development) of the ITU as an international organization in 1995.
Since ISOC is a membership organization itself, it can, of course, delega=
te one of its members to represent it, and certainly any duly authorized =
official of the ISOC (e.g., officer, trustee, etc.) can represent the ISO=
C in ITU Sector activities. The Internet Architecture Board (IAB), accor=
ding to the Overview presented on its Web site is =22a technical advisory=
group of the Internet Society =5Bwhose responsibilities include acting=5D=
as representative of the interests of the Internet Society in liaison re=
lationships with other organizations concerned with standards and other t=
echnical and organizational issues relevant to the world-wide Internet.=22=
At the same time, ISOC has appointed a Vice President for Standards (cu=
rrently Scott Bradner), who is also an elected trustee of the ISOC and a =
member of the Internet Engineering Steering Group (IESG), to serve as a =22=
liaison=22 to the IETF. Scott is also the designated =22liaison represen=
tative=22 from the IESG to the ITU. So, it would seem that, any official=
of the ISOC, the IAB, or the IESG, or any duly appointed representative =
from among the membership ranks of the ISOC, could represent the ISOC in =
the ITU Sectors, with the approval of the ISOC.
That said, it would seem that Mr. Shaw was overly generous in his remark =
that =22the IETF is a member of the ITU because ISOC is sort of the paren=
t body of the IETF, and ISOC is a member -- the Internet Society is a mem=
ber of the ITU also -- or a member of the telecommunication standardizati=
on sector.=22 Even though some individuals in the IETF (the chair, and t=
he area directors) automatically hold positions in the IESG, this should =
not be construed as meaning that the ISOC membership extends to the IETF =
as a result. In short, ISOC is a Sector member, ISOC is not a member of =
the ITU, and IETF is not a Sector member.
The IETF and various ITU-T Study Groups have, nevertheless, communicated =
with one another through liaison statements, since the IETF is viewed (by=
the ITU) as a standards consortium or forum (a la the ATM Forum). This =
is in addition to ISOC being a Sector member, which gives ISOC the right =
to attend and to participate in Sector meetings.
Hope this helps to clarify a somewhat cloudy topic. BTW, all this is my =
analysis of the topic, given a little over a decade of dealing with the I=
TU as a basis; i.e., this is not an =22official=22 position of any of the=
organizations named above.
Vito P. Jokubaitis
----------
From: =09Herman R. Silbiger
Sent: =09Sunday, June 08, 1997 9:49 AM
To: =09'ietf=40ietf.org'; 'Jim Fleming'
Cc: =09'newdom=40ar.com'
Subject: =09RE: ITU/ISOC/IETF
ISOC is a member of the Telecommunication Standardization Sector of the I=
TU. ISOC can therefore delegate its members to attend ITU-T meetings and=
offer technical contributions. To attend a particular meeting a communi=
cation should be sent from ISOC management designating the individuals wh=
o will be attending a particular meeting representing ISOC. I personally=
have never seen anyone with an ISOC badge at a meeting, nor have I seen =
any ISOC contributions.
Disclaimer: The above is my interpretation of the situation. I am sure =
that the ITU-T secretariat can clarify the situation.
Herman Silbiger
Etc., etc.
----------
From: =09Jim Fleming=5BSMTP:JimFleming=40unety.net=5D
Sent: =09Saturday, June 07, 1997 10:48 PM
To: =09'ietf=40ietf.org'
Cc: =09'newdom=40ar.com'
Subject: =09ITU/ISOC/IETF
Is the IETF really a member of the ITU ?
=40=40=40=40 http://aska.glocom.ac.jp/resa/APPLe/B-Shaw.html
Robert Shaw, International Telecommunication Union (ITU),
APPLe Workshop, Montreal, 28 June 1996
=22In fact, one could even say that the IETF is a member
of the ITU because ISOC is sort of the parent body of the
IETF, and ISOC is a member -- the Internet Society is a
member of the ITU also -- or a member of the telecommunication
standardization sector.=22
=40=40=40=40=40=40=40=40=40=40=40=40=40=40=40=40=40=40=40=40=40=40=40=40=40=
=40=40=40
--
Jim Fleming
Unir Corporation
http://www.Unir.Corp
Received: from ietf.org by ietf.org id aa16117; 9 Jun 97 16:30 EDT
Received: from alpha1.Reston.mci.net by ietf.org id aa15992; 9 Jun 97 16:24 EDT
Received: from vcerf.mci.net ([166.45.25.23])
by ALPHA1.RESTON.MCI.NET (PMDF V5.1-8 #8388)
with SMTP id <01IJVIDXW0OE002FKC at ALPHA1.RESTON.MCI.NET> for ietf at ietf.org;
Mon, 9 Jun 1997 16:20:57 EDT
Date: Mon, 09 Jun 1997 16:12:53 -0400
Sender:ietf-request at ietf.org
From: "vinton g. cerf" <vcerf at mci.net>
Subject: RE: ITU/ISOC/IETF
X-Sender: vcerf at alpha1.reston.mci.net
To: Vito Peter Jokubaitis <vjokubaitis at attmail.com>, ietf at ietf.org,
JimFleming at unety.net, hsilbiger at exit109.com
Cc: newdom at ar.com
Message-id: <3.0.32.19970609161249.00ac4b94 at alpha1.reston.mci.net>
MIME-version: 1.0
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Content-type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
Herman is not right.
ISOC IS a class "m" member of the ITU and has established
a means for ITU-T to make direct reference to Internet Standards
developed by IETF (which operates under the auspices of ISOC).
The procedure was undertaken to facilitate exchange of
information and working group participation between ITU-T
working parties and various IETF working groups. ISOC and
IETF lose none of their autonomy in this arrangement.
Vint Cerf
At 10:07 AM 6/9/97 -0500, Vito Peter Jokubaitis wrote:
>Herman's right!
>
>ISOC is NOT a member of the ITU. Membership in the ITU is restricted to
governments. ISOC joined the Sectors (Telecommunications,
Radiocommunications, Development) of the ITU as an international
organization in 1995.
>
Received: from ietf.org by ietf.org id aa22310; 9 Jun 97 22:28 EDT
Received: from hiway1.exit109.com by ietf.org id aa20924; 9 Jun 97 22:18 EDT
Received: from ppp55-rb.exit109.com (ppp20-rb.exit109.com [205.164.176.147]) by hiway1.exit109.com (8.8.5/8.7.3) with SMTP id WAA15066; Mon, 9 Jun 1997 22:14:28 -0400 (EDT)
Received: by ppp55-rb.exit109.com with Microsoft Mail
id <01BC7522.744BE500 at ppp55-rb.exit109.com>; Mon, 9 Jun 1997 22:14:10 -0400
Message-ID: <01BC7522.744BE500 at ppp55-rb.exit109.com>
Sender:ietf-request at ietf.org
From: "Herman R. Silbiger" <hsilbiger at exit109.com>
To: Vito Peter Jokubaitis <vjokubaitis at attmail.com>,
"ietf at ietf.org" <ietf at ietf.org>, "'vinton g. cerf'" <vcerf at mci.net>
Cc: "newdom at ar.com" <newdom at ar.com>
Subject: RE: ITU/ISOC/IETF
Date: Mon, 9 Jun 1997 16:42:16 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Source-Info: From (or Sender) name not authenticated.
Vint,
Please refer to my original message, reproduced at the end of this =
exchange. I still believe that all I stated is correct. Yes, =
procedures now exist for referencing RFCs, but that capability is =
independent of ISOC being a member.
Herman
----------
From: vinton g. cerf[SMTP:vcerf at mci.net]
Sent: Monday, June 09, 1997 4:12 PM
To: Vito Peter Jokubaitis; ietf at ietf.org; JimFleming at unety.net; =
hsilbiger at exit109.com
Cc: newdom at ar.com
Subject: RE: ITU/ISOC/IETF
Herman is not right.
ISOC IS a class "m" member of the ITU and has established
a means for ITU-T to make direct reference to Internet Standards
developed by IETF (which operates under the auspices of ISOC).
I said that ISOC is a member, not a Member.
The procedure was undertaken to facilitate exchange of
information and working group participation between ITU-T
working parties and various IETF working groups. ISOC and
IETF lose none of their autonomy in this arrangement.
Vint Cerf
At 10:07 AM 6/9/97 -0500, Vito Peter Jokubaitis wrote:
>Herman's right!
>
>ISOC is NOT a member of the ITU. Membership in the ITU is restricted =
to
governments. ISOC joined the Sectors (Telecommunications,
Radiocommunications, Development) of the ITU as an international
organization in 1995.
>
Original statement:
ISOC is a member of the Telecommunication Standardization Sector of the =
ITU. ISOC can therefore delegate its members to attend ITU-T meetings =
and offer technical contributions. To attend a particular meeting a =
communication should be sent from ISOC management designating the =
individuals who will be attending a particular meeting representing =
ISOC. =20
Received: from ietf.org by ietf.org id aa28219; 10 Jun 97 0:10 EDT
Received: from hiway1.exit109.com by ietf.org id aa28082; 9 Jun 97 23:55 EDT
Received: from ppp55-rb.exit109.com (ppp19-rb.exit109.com [205.164.176.146]) by hiway1.exit109.com (8.8.5/8.7.3) with SMTP id XAA26649; Mon, 9 Jun 1997 23:50:49 -0400 (EDT)
Received: by ppp55-rb.exit109.com with Microsoft Mail
id <01BC752F.E1B3C920 at ppp55-rb.exit109.com>; Mon, 9 Jun 1997 23:50:17 -0400
Message-ID: <01BC752F.E1B3C920 at ppp55-rb.exit109.com>
Sender:ietf-request at ietf.org
From: "Herman R. Silbiger" <hsilbiger at exit109.com>
To: "'ietf at ietf.org'" <ietf at ietf.org>, "'vinton g. cerf'" <vcerf at mci.net>,
'Vito Jokubaitis' <vjokubaitis at attmail.com>
Cc: "'newdom at ar.com'" <newdom at ar.com>
Subject: RE: ITU/ISOC/IETF
Date: Mon, 9 Jun 1997 23:50:01 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Source-Info: From (or Sender) name not authenticated.
Vint,
Please refer to my original message, reproduced at the end of this =
exchange. I still believe that all I stated is correct. Yes, =
procedures now exist for referencing RFCs, but that capability is =
independent of ISOC being a member.
Herman
----------
From: vinton g. cerf[SMTP:vcerf at mci.net]
Sent: Monday, June 09, 1997 4:12 PM
To: Vito Peter Jokubaitis; ietf at ietf.org; JimFleming at unety.net; =
hsilbiger at exit109.com
Cc: newdom at ar.com
Subject: RE: ITU/ISOC/IETF
Herman is not right.
ISOC IS a class "m" member of the ITU and has established
a means for ITU-T to make direct reference to Internet Standards
developed by IETF (which operates under the auspices of ISOC).
I said that ISOC is a member, not a Member.
The procedure was undertaken to facilitate exchange of
information and working group participation between ITU-T
working parties and various IETF working groups. ISOC and
IETF lose none of their autonomy in this arrangement.
Vint Cerf
At 10:07 AM 6/9/97 -0500, Vito Peter Jokubaitis wrote:
>Herman's right!
>
>ISOC is NOT a member of the ITU. Membership in the ITU is restricted =
to
governments. ISOC joined the Sectors (Telecommunications,
Radiocommunications, Development) of the ITU as an international
organization in 1995.
>
Original statement:
ISOC is a member of the Telecommunication Standardization Sector of the =
ITU. ISOC can therefore delegate its members to attend ITU-T meetings =
and offer technical contributions. To attend a particular meeting a =
communication should be sent from ISOC management designating the =
individuals who will be attending a particular meeting representing =
ISOC. =20
Received: from ietf.org by ietf.org id aa29522; 10 Jun 97 1:37 EDT
Received: from cnri by ietf.org id aa29403; 10 Jun 97 1:30 EDT
Received: from [164.129.225.7] by CNRI.Reston.VA.US id aa01625;
10 Jun 97 1:30 EDT
Received: from by eux100 with SMTP
(1.40.112.8/16.2) id AA218830230; Tue, 10 Jun 1997 07:23:50 +0200
Sender:ietf-request at ietf.org
From: Rajeev.BHATIA at st.com
X-Openmail-Hops: 2
Date: Tue, 10 Jun 97 10:53:13 +0500
Message-Id: <H000006f00d9c466 at MHS>
In-Reply-To: <3.0.2.32.19970610004533.007b4bc0 at norlink.net>
Subject:
Mime-Version: 1.0
Cc: I-BBOARD at spcvxa.spc.edu, I-FINGER at spcvxa.spc.edu,
IAPSY-L at uacsc2.albany.edu, IBJ-L at poniecki.haas.berkeley.edu,
IBM-NETS at bitnic.cren.net, IBM-SRD at vm1.nodak.edu,
IBMPC-KIDS at minerva.sws.uiuc.edu, IBMTCP-L at pucc.princeton.edu,
ICON-GROUP at arizona.edu, ICYRA at mailhost.tcs.tulane.edu,
IDMS-L at uga.cc.uga.edu, IETF at CNRI.Reston.VA.US,
IETF-ANNOUNCE at CNRI.Reston.VA.US, IFIP-GTWY at ics.uci.edu,
IFPHEN-L at wsuvm1.csc.wsu.edu, IFREEDOM at snoopy.ucis.dal.ca,
IHP-NET at interaccess.com, ILAS-NET at technion.technion.ac.il, ILUG at sgi.com,
IMAGE-L at vm.ege.edu.tr, IMAGEN-L at bolis.sf-bay.org, IMMUNE at weber.ucsd.edu,
IND-NET at listproc.wsu.edu, INDIA-IN-LANGUAGES at ee.rochester.edu,
INDIA-L at vm.temple.edu, INDIGO-GIRLS at cgrg.ohio-state.edu,
INDOLOGY at liverpool.ac.uk, INET-MARKETING at einet.net, INFO-1100 at anzus.com,
INFO-68K at berkeley.edu, INFO-ADA at ns1.sw-eng.falls-church.va.us,
INFO-ANDREW at andrew.cmu.edu, INFO-ANDREW-BUGS at andrew.cmu.edu,
INFO-APPLE at brl.mil, INFO-APPLETALK at andrew.cmu.edu,
INFO-ATARI16 at naucse.cse.nau.edu, INFO-ATARI16 at vm.marist.edu,
INFO-C at research.att.com, INFO-CLUSTERS at larc.nasa.gov,
INFO-CONVEX at pemrac.space.swri.edu, INFO-FUTURES at world.std.com,
INFO-GNU-MSDOS at sun.soe.clarkson.edu, INFO-HIGH-AUDIO at introl.com,
INFO-INGRES at math.ams.org, INFO-IRIS at arl.mil,
INFO-KERMIT at watsun.cc.columbia.edu, INFO-LAW at brl.mil,
INFO-M2 at bitnic.cren.net, INFO-MAC at smi.stanford.edu,
INFO-NETS-REQUEST at think.com, INFO-PDP11 at transarc.com,
INFO-PROGRAPH at grove.iup.edu, INFO-PYRAMID-REQUEST at mimsy.cs.umd.edu,
INFO-SOLBOURNE at acsu.buffalo.edu, INFO-TAHOE at uwm.edu, INFO-UNIX at brl.mil,
INFO-VAX at mvb.saic.com, INFO-ZIP at wkuvx1.wku.edu,
INFORMIX-LIST at rmy.emory.edu, INFOTERRA at pan.cedar.univie.ac.at,
INGRAFX at ubvm.cc.buffalo.edu, INT-CONTROLS at financenet.gov,
INT-LAW at vm1.spcs.umn.edu, INTDEV-L at uriacc.uri.edu, INTERFACES-P-M at crim.ca,
INTUDM-L at utepvm.ep.utexas.edu, IOOB-L at uga.cc.uga.edu,
IOUDAIOS%YORKVM1.BITNET at cunyvm.cuny.edu, IPCT-L at guvm.ccf.georgetown.edu,
IPE-ISA-L at mach1.wlu.ca, IPSC-MANAGERS at nas.nasa.gov,
IPSC-USERS at nas.nasa.gov, IR-LIST%IRLEARN.BITNET at vm1.nodak.edu,
IRL-POL at irlearn.ucd.ie, ISLAM-L at ulkyvm.louisville.edu,
ISSS at jhuvm.hcf.jhu.edu, ITALIAN-CARS at balltown.cma.com,
ITALIC-L at irlearn.ucd.ie, ITISALAT at guvm.georgetown.ccf.edu,
IVTHERAPY-L at netcom.com
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
help
Received: from ietf.org by ietf.org id aa01527; 10 Jun 97 10:09 EDT
Received: from email.archlab.tuwien.ac.at by ietf.org id aa01096;
10 Jun 97 9:50 EDT
Received: by email.archlab.tuwien.ac.at (950413.SGI.8.6.12/940406.SGI.AUTO)
id PAA23587; Tue, 10 Jun 1997 15:43:43 +0200
Date: Tue, 10 Jun 1997 15:43:42 +0200 (MDT)
Sender:ietf-request at ietf.org
From: Sascha Ignjatovic <signato at email.archlab.tuwien.ac.at>
To: "Herman R. Silbiger" <hsilbiger at exit109.com>
cc: Vito Peter Jokubaitis <vjokubaitis at attmail.com>,
"ietf at ietf.org" <ietf at ietf.org>, "'vinton g. cerf'" <vcerf at mci.net>,
"newdom at ar.com" <newdom at ar.com>
Subject: RE: ITU/ISOC/IETF
In-Reply-To: <01BC7522.744BE500 at ppp55-rb.exit109.com>
Message-ID: <Pine.SGI.3.91.970610152443.22281A-100000 at email.archlab.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 9 Jun 1997, Herman R. Silbiger wrote:
> Vint,
>
> Please refer to my original message, reproduced at the end of this exchange.
I still believe that all I stated is correct. Yes, procedures now
exist for referencing RFCs, but that capability is independent of ISOC
being a member. >
> Herman
yes but what this say us ?
what is wrong beeing a member ?
see i am a stupid fool but even i understand that cooperation is all
internet is about
if the internet is good than everyone should have it
why not "use" and cooperate with organisation who can help to have a
"planetary covered internet"
the cooperation with itu is strategic good and should help the future
development/establishment of the global internet
as dr.cerf says internet isoc and ietf will not loose their autonomy thru
this cooperation also the itu and other organisations have the right to
get benefit of the internet technology so they should
if i put it simply/stupid as i am
not the telecomms will take the internet "over"
the internet will take them "over" :-)
becouse there is no other thing "than allincorporating internet" on earth:-)
"the only chance to survive the ignorance and chaos ":-)
"the first global/planetary intelligence":-)
sasha
ps.this mail was writen in thankfulnes to and honor of all
internet developers
> From: vinton g. cerf[SMTP:vcerf at mci.net]
> Sent: Monday, June 09, 1997 4:12 PM
> To: Vito Peter Jokubaitis; ietf at ietf.org; JimFleming at unety.net; hsilbiger at exit109.com
> Cc: newdom at ar.com
> Subject: RE: ITU/ISOC/IETF
>
> Herman is not right.
>
> ISOC IS a class "m" member of the ITU and has established
> a means for ITU-T to make direct reference to Internet Standards
> developed by IETF (which operates under the auspices of ISOC).
>
> I said that ISOC is a member, not a Member.
>
> The procedure was undertaken to facilitate exchange of
> information and working group participation between ITU-T
> working parties and various IETF working groups. ISOC and
> IETF lose none of their autonomy in this arrangement.
>
> Vint Cerf
Received: from ietf.org by ietf.org id aa02022; 10 Jun 97 10:25 EDT
Received: from cnri by ietf.org id aa00539; 10 Jun 97 3:03 EDT
Received: from fingon.norlink.net by CNRI.Reston.VA.US id aa02375;
10 Jun 97 3:03 EDT
Received: from quad100 (gandalf27.norlink.net [204.50.130.127])
by fingon.norlink.net (8.8.4/8.8.4) with SMTP
id AAA15436; Tue, 10 Jun 1997 00:54:50 -0400
Message-Id: <3.0.2.32.19970610004533.007b4bc0 at norlink.net>
X-Sender: jsm at norlink.net (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 b4 (32)
X-Priority: 1 (Highest)
Date: Tue, 10 Jun 1997 00:45:33 -0400
To: I-BBOARD at spcvxa.spc.edu, I-FINGER at spcvxa.spc.edu,
IAPSY-L at uacsc2.albany.edu, IBJ-L at poniecki.haas.berkeley.edu,
IBM-NETS at bitnic.cren.net, IBM-SRD at vm1.nodak.edu,
IBMPC-KIDS at minerva.sws.uiuc.edu, IBMTCP-L at pucc.princeton.edu,
ICON-GROUP at arizona.edu, ICYRA at mailhost.tcs.tulane.edu,
IDMS-L at uga.cc.uga.edu, IETF-ANNOUNCE at CNRI.Reston.VA.US,
IETF at CNRI.Reston.VA.US, IFIP-GTWY at ics.uci.edu,
IFPHEN-L at wsuvm1.csc.wsu.edu, IFREEDOM at snoopy.ucis.dal.ca,
IHP-NET at interaccess.com, ILAS-NET at technion.technion.ac.il, ILUG at sgi.com,
IMAGE-L at vm.ege.edu.tr, IMAGEN-L at bolis.sf-bay.org, IMMUNE at weber.ucsd.edu,
IND-NET at listproc.wsu.edu, INDIA-IN-LANGUAGES at ee.rochester.edu,
INDIA-L at vm.temple.edu, INDIGO-GIRLS at cgrg.ohio-state.edu,
INDOLOGY at liverpool.ac.uk, INET-MARKETING at einet.net, INFO-1100 at anzus.com,
INFO-68K at berkeley.edu, INFO-ADA at ns1.sw-eng.falls-church.va.us,
INFO-ANDREW-BUGS at andrew.cmu.edu, INFO-ANDREW at andrew.cmu.edu,
INFO-APPLE at brl.mil, INFO-APPLETALK at andrew.cmu.edu,
INFO-ATARI16 at naucse.cse.nau.edu, INFO-ATARI16 at vm.marist.edu,
INFO-C at research.att.com, INFO-CLUSTERS at larc.nasa.gov,
INFO-CONVEX at pemrac.space.swri.edu, INFO-FUTURES at world.std.com,
INFO-GNU-MSDOS at sun.soe.clarkson.edu, INFO-HIGH-AUDIO at introl.com,
INFO-INGRES at math.ams.org, INFO-IRIS at arl.mil,
INFO-KERMIT at watsun.cc.columbia.edu, INFO-LAW at brl.mil,
INFO-M2 at bitnic.cren.net, INFO-MAC at smi.stanford.edu,
INFO-NETS-REQUEST at think.com, INFO-PDP11 at transarc.com,
INFO-PROGRAPH at grove.iup.edu, INFO-PYRAMID-REQUEST at mimsy.cs.umd.edu,
INFO-SOLBOURNE at acsu.buffalo.edu, INFO-TAHOE at uwm.edu, INFO-UNIX at brl.mil,
INFO-VAX at mvb.saic.com, INFO-ZIP at wkuvx1.wku.edu,
INFORMIX-LIST at rmy.emory.edu, INFOTERRA at pan.cedar.univie.ac.at,
INGRAFX at ubvm.cc.buffalo.edu, INT-CONTROLS at financenet.gov,
INT-LAW at vm1.spcs.umn.edu, INTDEV-L at uriacc.uri.edu, INTERFACES-P-M at crim.ca,
INTUDM-L at utepvm.ep.utexas.edu, IOOB-L at uga.cc.uga.edu,
IOUDAIOS%YORKVM1.BITNET at cunyvm.cuny.edu, IPCT-L at guvm.ccf.georgetown.edu,
IPE-ISA-L at mach1.wlu.ca, IPSC-MANAGERS at nas.nasa.gov,
IPSC-USERS at nas.nasa.gov, IR-LIST%IRLEARN.BITNET at vm1.nodak.edu,
IRL-POL at irlearn.ucd.ie, ISLAM-L at ulkyvm.louisville.edu,
ISSS at jhuvm.hcf.jhu.edu, ITALIAN-CARS at balltown.cma.com,
ITALIC-L at irlearn.ucd.ie, ITISALAT at guvm.georgetown.ccf.edu,
IVTHERAPY-L at netcom.com
Sender:ietf-request at ietf.org
From: jsm at fingon.norlink.net
Subject: HELP URGENTLY NEEDED PLEASE
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
YOUR HELP IS URGENTLY NEEDED PLEASE
Dear friend,
My name is Mike Chenard, and I am a student here in Thunder Bay, Ontario,
Canada, with another year to go before graduating with my college diploma.
I am sending you this e-mail because I urgently and desperately need your
HELP.
The summer job opportunities for students in my community are less than
adequate, and are caused by an extremely slow economic recovery from our
recent recession. For every summer job available for a student,
approximately 60 applications are received. I have personally submitted 87
resumes for minimum wage jobs' without even receiving a response.
The total cost for my last year at the college will cost me $14,000.
Without the possibility of obtaining a summer job to help me finance this
cost, I will not be able to complete my last year of education. Therefore,
I will not be able to fulfill my dream of graduating with a college diploma.
Face with this situation, I am appealing for your help and generosity.
Although my pride will suffer from this request, I need to keep my
education as my priority. I am asking you (more like begging you) to help
me by sending me $5, or whatever you feel you can afford, to help finance
my last year at the college. I figure that your generosity plus all others
who help me, will allow me to fulfill my dream of obtaining my college
diploma.
Please send $5 or whatever amount you feel you can afford to:
Mike Chenard
337 Lark Street
Thunder Bay, Ontario
Canada, P7B 1P4
I wish to express my sincere thank's for your support toward my education.
Please feel happy and full of pride with the knowledge that you have help a
student fulfill his dream of completing his education.
Let me sincerely thank you for your help.
Mike Chenard
Received: from ietf.org by ietf.org id aa03033; 10 Jun 97 10:39 EDT
Received: from ietf.ietf.org by ietf.org id aa02353; 10 Jun 97 10:30 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-li-hsrp-00.txt
Date: Tue, 10 Jun 1997 10:30:04 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706101030.aa02353 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Hot Standby Router Protocol (HSRP)
Author(s) : T. Li, B. Cole, P. Morton, D. Li
Filename : draft-li-hsrp-00.txt
Pages : 12
Date : 06/09/1997
The memo specifies the Hot Standby Router Protocol (HSRP). The goal of the
protocol is to allow hosts to appear to use a single router and to maintain
connectivity even if the actual first hop router they are using fails.
Multiple routers participate in this protocol and in concert create the
illusion of a single virtual router. The protocol insures that one and
only one of the routers is forwarding packets on behalf of the virtual
router. End hosts forward their packets to the virtual router.
The router forwarding packets is known as the active router. A standby
router is selected to replace the active router should it fail. The protocol
provides a mechanism for determining active and standby routers, using the
IP addresses on the participating routers. If an active router fails a
standby router can take over without a major interruption in the host's
connectivity. This memo also discusses the ARP, MAC address, and security
issues with this protocol.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-li-hsrp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-li-hsrp-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-li-hsrp-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970609103800.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-li-hsrp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-li-hsrp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970609103800.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03050; 10 Jun 97 10:39 EDT
Received: from ietf.ietf.org by ietf.org id aa02312; 10 Jun 97 10:29 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
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-test-03.txt
Date: Tue, 10 Jun 1997 10:29:53 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706101029.aa02312 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 Tests for ATM Management
Author(s) : M. Noto, K. Tesink
Filename : draft-ietf-atommib-test-03.txt
Pages : 31
Date : 06/09/1997
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for managing ATM-based
interfaces, devices, networks and services in addition to those defined in
the ATM MIB [1], to provide additional support for the management of ATM
Loopback Tests.
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-test-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-test-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-atommib-test-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970609101035.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-atommib-test-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-atommib-test-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970609101035.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03045; 10 Jun 97 10:39 EDT
Received: from ietf.ietf.org by ietf.org id aa02460; 10 Jun 97 10:31 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-nai-04.txt
Date: Tue, 10 Jun 1997 10:30:26 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706101031.aa02460 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Roaming Operations Working
Group of the IETF.
Title : The Network Access Identifier
Author(s) : B. Aboba
Filename : draft-ietf-roamops-nai-04.txt
Pages : 4
Date : 06/09/1997
In order to enhance the interoperability of roaming and tunneling services,
it is desirable to have a standardized method for identifying users. This
document proposes syntax for the Network Access Identifier (NAI). It is
expected that this will be of interest for support of roaming as well as
tunneling. "Roaming capability" may be loosely defined as the ability to
use any one of multiple Internet service providers (ISPs), while
maintaining a formal, customer-vendor relationship with only one. Examples
of cases where roaming capability might be required include ISP
"confederations" and ISP-provided corporate network access support.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-nai-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-nai-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-nai-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970609115544.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-nai-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-nai-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970609115544.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03042; 10 Jun 97 10:39 EDT
Received: from ietf.ietf.org by ietf.org id aa02377; 10 Jun 97 10:30 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: urn-ietf at bunyip.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-urn-ietf-01.txt
Date: Tue, 10 Jun 1997 10:30:16 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706101030.aa02377 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Names
Working Group of the IETF.
Title : A URN Namespace for IETF Documents
Author(s) : R. Moats
Filename : draft-ietf-urn-ietf-01.txt
Pages : 4
Date : 06/09/1997
A system for Uniform Resource Names (URNs) must be capable of supporting
new naming systems. As an example of the sort of information that needs to
be supplied when proposing new namepsaces, this document presents a naming
system based on the RFC family of documents (RFCs, STDs, and FYIs)
developed by the IETF and published by the RFC editor and the minutes of
working groups (WG) and birds of a feather (BOF) meetings that occur during
IETF conferences. This namespace can be supported within the URN framework
and the currently proposed syntax for URNs.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-urn-ietf-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-ietf-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-urn-ietf-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970609114527.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-urn-ietf-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-urn-ietf-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970609114527.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03046; 10 Jun 97 10:39 EDT
Received: from ietf.ietf.org by ietf.org id aa02680; 10 Jun 97 10:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-ldif-01.txt
Date: Tue, 10 Jun 1997 10:33:13 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706101033.aa02680 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : The LDAP Data Interchange Format (LDIF) - Technical
Specification
Author(s) : G. Good
Filename : draft-ietf-asid-ldif-01.txt
Pages : 9
Date : 06/09/1997
This document describes a file format suitable for describing directory
information and modifications made to directory information. The file
format, known as LDIF, for LDAP Data Interchange Format, is typically used
to import and export directory information between LDAP-based directory
servers, and to describe a set of changes which are to be applied to a
directory.
There are a number of situations where a common interchange format is
desirable. For example, one might wish to export a copy of the contents of
a directory server to a file, move that file to a different machine, and
import the contents into a second directory server.
Additionally, by using a well-defined interchange format, development of
data import tools from legacy systems is facilitated. A fairly simple set
of tools written in awk or perl can, for example, convert a database of
personnel information into an LDIF file, which can then be imported into a
directory server, regardless of the internal database representation the
target directory server uses.
The key words "MUST", "MAY", and "SHOULD" used in this document are
to be interpreted as described in [7].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-asid-ldif-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldif-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-ldif-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970609143655.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldif-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldif-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970609143655.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03032; 10 Jun 97 10:39 EDT
Received: from ietf.ietf.org by ietf.org id aa02335; 10 Jun 97 10:30 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-ldapv3-attributes-05.txt
Date: Tue, 10 Jun 1997 10:30:01 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706101030.aa02335 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : Lightweight Directory Access Protocol (v3):
Attribute Syntax Definitions
Author(s) : M. Wahl, A. Coulbeck, T. Howes, S. Kille
Filename : draft-ietf-asid-ldapv3-attributes-05.txt
Pages : 24
Date : 06/09/1997
The Lightweight Directory Access Protocol (LDAP) [1] requires that the
contents of AttributeValue fields in protocol elements be octet strings.
This document defines a set of syntaxes for LDAPv3, and the rules by which
attribute values of these syntaxes are represented as octet strings for
transmission in the LDAP protocol. The syntaxes defined in this document
are referenced by this and other documents that define attribute types.
This document also defines the set of attribute types which LDAP servers
should support.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-asid-ldapv3-attributes-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3-attributes-05.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-ldapv3-attributes-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
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: <19970609104250.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldapv3-attributes-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldapv3-attributes-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970609104250.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03048; 10 Jun 97 10:39 EDT
Received: from ietf.ietf.org by ietf.org id aa02459; 10 Jun 97 10:30 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-roamreq-04.txt
Date: Tue, 10 Jun 1997 10:30:21 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706101030.aa02459 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Roaming Operations Working
Group of the IETF.
Title : Dialup Roaming Requirements
Author(s) : B. Aboba, G. Zorn
Filename : draft-ietf-roamops-roamreq-04.txt
Pages : 13
Date : 06/09/1997
This document describes the features required for the provision of "roaming
capability" for dialup Internet users, as well as offering some suggestions
for future protocol standardization work. "Roaming capability" is defined
as the ability to use any one of multiple Internet service providers
(ISPs), while maintaining a formal, customer-vendor relationship with only
one. Examples of cases where roaming capability might be required include
ISP "confederations" and ISP-provided corporate network access support.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-roamreq-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-roamreq-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-roamreq-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970609115958.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-roamreq-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-roamreq-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970609115958.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03043; 10 Jun 97 10:39 EDT
Received: from ietf.ietf.org by ietf.org id aa02294; 10 Jun 97 10:29 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: if-mib 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-ifmib-testmib-03.txt
Date: Tue, 10 Jun 1997 10:29:49 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706101029.aa02294 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 Interfaces MIB Working Group
of the IETF.
Title : Definitions of Managed Objects for System and Interface
Testing
Author(s) : M. Greene, K. McCloghrie, K. Tesink
Filename : draft-ietf-ifmib-testmib-03.txt
Pages : 19
Date : 06/09/1997
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for testing systems
and interfaces. This memo replaces the objects originally defined in the
ifTestGroup of RFC1573, the IF-MIB [6], which have been deprecated.
This memo specifies a MIB module in a manner that is both compliant to the
SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ifmib-testmib-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ifmib-testmib-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ifmib-testmib-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970609100322.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ifmib-testmib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ifmib-testmib-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970609100322.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03039; 10 Jun 97 10:39 EDT
Received: from ietf.ietf.org by ietf.org id aa02437; 10 Jun 97 10:30 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-acap+ at andrew.cmu.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-acap-mlsf-01.txt
Date: Tue, 10 Jun 1997 10:30:35 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706101030.aa02437 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 Application Configuration
Access Protocol Working Group of the IETF.
Title : Multi-Lingual String Format (MLSF)
Author(s) : C. Newman
Filename : draft-ietf-acap-mlsf-01.txt
Pages : 14
Date : 06/09/1997
The IAB charset workshop [IAB-CHARSET] concluded that for human readable
text there should always be a way to specify the natural language. Many
protocols are designed with an attribute-value model (including RFC 822,
HTTP, LDAP, SNMP, DHCP, and ACAP) which stores many small human readable
text strings. The primary function of an attribute-value model is to
simplify both extensibility and searchability. A solution is needed to
provide language tags in these small human readable text strings, which
does not interfere with these primary functions.
This specification defines MLSF (Multi-Lingual String Format) which applies
another layer of encoding on top of UTF-8 [UTF-8] to permit the addition of
language tags anywhere within a text string. In addition, it defines an
alternate form which can be used to include alternative representations of
the same text in different character sets. MLSF has the property that
UTF-8 is a proper subset of MLSF. This preserves the searchability
requirement of the attribute-value model.
Appendix F of this document includes a brief discussion of the background
behind MLSF and why some other potential solutions were rejected
for this purpose.
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-acap-mlsf-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-acap-mlsf-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-acap-mlsf-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970609133444.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-acap-mlsf-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-acap-mlsf-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970609133444.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03391; 10 Jun 97 10:41 EDT
Received: from ietf.ietf.org by ietf.org id aa03057; 10 Jun 97 10:39 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-exp-rupp-01.txt
Date: Tue, 10 Jun 1997 10:39:17 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706101039.aa03057 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Protocol for the Transmission of Net News Articles
over IP multicast.
Author(s) : H. Rupp
Filename : draft-rfced-exp-rupp-01.txt
Pages : 9
Date : 06/06/1997
This protocol provides a way to use the IP multicast infrastructure to
transmit NetNews articles between news servers. Doing so will reduce the
bandwidth that is actually needed for transmission via NNTP. This does not
affect how news reading clients communicate with servers.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-rfced-exp-rupp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-exp-rupp-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-exp-rupp-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970606104732.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-exp-rupp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-exp-rupp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970606104732.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03393; 10 Jun 97 10:41 EDT
Received: from ietf.ietf.org by ietf.org id aa03282; 10 Jun 97 10:40 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-ids at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ids-iwps-schema-spec-06.txt
Date: Tue, 10 Jun 1997 10:40:24 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706101040.aa03282 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integrated Directory
Services Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : A Common Schema for the Internet White Pages Service
Author(s) : T. Genovese, B. Jennings
Filename : draft-ietf-ids-iwps-schema-spec-06.txt
Pages : 6
Date : 06/06/1997
This work is the result of the IETF Integrated Directory Services (IDS)
Working Group. The IDS Working Group proposes a standard specification for
a simple Internet White Pages service by defining a common schema for use
by the various White Pages servers. This schema is independent of specific
implementations of the White Pages service.
This document specifies the minimum set of core attributes of a White Pages
entry for an individual and describes how new objects with those attributes
can be defined and published. It does not describe how to represent other
objects in the White Pages service. Further, it does not address the
search sort expectations within a particular service.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ids-iwps-schema-spec-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ids-iwps-schema-spec-06.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ids-iwps-schema-spec-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
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: <19970606150105.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ids-iwps-schema-spec-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ids-iwps-schema-spec-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970606150105.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04356; 10 Jun 97 11:35 EDT
Received: from cnri by ietf.org id ab04175; 10 Jun 97 11:25 EDT
Received: from uucp2.msen.com by CNRI.Reston.VA.US id aa04926;
10 Jun 97 7:56 EDT
Received: from moby.UUCP (Ufanuc at localhost) by uucp2.msen.com (8.8.5/8.7.3) with UUCP id HAA04151 for cnri.reston.va.us!IETF; Tue, 10 Jun 1997 07:22:36 -0400 (EDT)
X-Authentication-Warning: uucp2.msen.com: Ufanuc set sender to moby!frc.com!iac using -f
Received: from ibex.frc.com by moby.frc.com with smtp
(Smail3.1.28.1 #5) id m0wbOVt-0003rAC; Tue, 10 Jun 97 06:50 EDT
Received: by ibex.frc.com (Smail3.1.28.1 #1)
id m0wbOVs-0007tFC; Tue, 10 Jun 97 06:50 EDT
Date: Tue, 10 Jun 1997 06:50:56 -0400 (EDT)
Sender:ietf-request at ietf.org
From: ic <iac at frc.com>
X-Sender: iac at ibex
To: jsm at fingon.norlink.net
cc: I-BBOARD at spcvxa.spc.edu, I-FINGER at spcvxa.spc.edu,
IAPSY-L at uacsc2.albany.edu, IBJ-L at poniecki.haas.berkeley.edu,
IBM-NETS at bitnic.cren.net, IBM-SRD at vm1.nodak.edu,
IBMPC-KIDS at minerva.sws.uiuc.edu, IBMTCP-L at pucc.princeton.edu,
ICON-GROUP at arizona.edu, ICYRA at mailhost.tcs.tulane.edu,
IDMS-L at uga.cc.uga.edu, IETF-ANNOUNCE at CNRI.Reston.VA.US,
IETF at CNRI.Reston.VA.US, IFIP-GTWY at ics.uci.edu,
IFPHEN-L at wsuvm1.csc.wsu.edu, IFREEDOM at snoopy.ucis.dal.ca,
IHP-NET at interaccess.com, ILAS-NET at technion.technion.ac.il, ILUG at sgi.com,
IMAGE-L at vm.ege.edu.tr, IMAGEN-L at bolis.sf-bay.org, IMMUNE at weber.ucsd.edu,
IND-NET at listproc.wsu.edu, INDIA-IN-LANGUAGES at ee.rochester.edu,
INDIA-L at vm.temple.edu, INDIGO-GIRLS at cgrg.ohio-state.edu,
INDOLOGY at liverpool.ac.uk, INET-MARKETING at einet.net, INFO-1100 at anzus.com,
INFO-68K at berkeley.edu
Subject: Re: HELP URGENTLY NEEDED PLEASE
In-Reply-To: <3.0.2.32.19970610004533.007b4bc0 at norlink.net>
Message-ID: <Pine.SOL.3.91.970610064819.12030D-100000 at ibex>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
What school do u go to? And what are you studying? This should probably
be verified before people start sending you even 1 cent !!!
I would try Toronto or New York for jobs
On Tue, 10 Jun 1997 jsm at fingon.norlink.net wrote:
> YOUR HELP IS URGENTLY NEEDED PLEASE
>
> Dear friend,
>
> My name is Mike Chenard, and I am a student here in Thunder Bay, Ontario,
> Canada, with another year to go before graduating with my college diploma.
> I am sending you this e-mail because I urgently and desperately need your
> HELP.
>
> The summer job opportunities for students in my community are less than
> adequate, and are caused by an extremely slow economic recovery from our
> recent recession. For every summer job available for a student,
> approximately 60 applications are received. I have personally submitted 87
> resumes for minimum wage jobs' without even receiving a response.
>
> The total cost for my last year at the college will cost me $14,000.
> Without the possibility of obtaining a summer job to help me finance this
> cost, I will not be able to complete my last year of education. Therefore,
> I will not be able to fulfill my dream of graduating with a college diploma.
>
> Face with this situation, I am appealing for your help and generosity.
> Although my pride will suffer from this request, I need to keep my
> education as my priority. I am asking you (more like begging you) to help
> me by sending me $5, or whatever you feel you can afford, to help finance
> my last year at the college. I figure that your generosity plus all others
> who help me, will allow me to fulfill my dream of obtaining my college
> diploma.
>
> Please send $5 or whatever amount you feel you can afford to:
>
> Mike Chenard
> 337 Lark Street
> Thunder Bay, Ontario
> Canada, P7B 1P4
>
> I wish to express my sincere thank's for your support toward my education.
> Please feel happy and full of pride with the knowledge that you have help a
> student fulfill his dream of completing his education.
>
> Let me sincerely thank you for your help.
>
>
> Mike Chenard
>
Received: from ietf.org by ietf.org id aa15112; 10 Jun 97 18:07 EDT
Received: from zephyr.isi.edu by ietf.org id aa14978; 10 Jun 97 18:01 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
id <AA23933>; Tue, 10 Jun 1997 14:57:40 -0700
Message-Id: <199706102157.AA23933 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: FYI 30, RFC 2151 on Internet & TCP/IP Tools & Utilities
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 10 Jun 97 14:57:40 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.
FYI 30:
RFC 2151:
Title: A Primer On Internet and TCP/IP Tools
and Utilities
Author: G. Kessler, S. Shepard
Date: June 1997
Mailbox: kumquat at hill.com, s.shepard at hill.com
Pages: 52
Characters: 114130
Obsoletes: 1739
URL: ftp://ds.internic.net/rfc/rfc2151.txt
This memo is an introductory guide to many of the most commonly-
available TCP/IP and Internet tools and utilities. It also describes
discussion lists accessible from the Internet, ways to obtain Internet
and TCP/IP documents, and some resources that help users weave their
way through the Internet.
This memo provides information for the Internet community.
This memo does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970610144040.RFC at ISI.EDU>
SEND /rfc/rfc2151.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2151.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970610144040.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07795; 11 Jun 97 10:09 EDT
Received: from Eleventh.MR.Net by ietf.org id aa05346; 11 Jun 97 8:29 EDT
Received: by eleventh (NX5.67e/SMI-4.1.N930805)
id AA01465; Wed, 11 Jun 97 07:20:56 -0500
Message-Id: <9706111220.AA01465 at eleventh>
Mime-Version: 1.0 (NeXT Mail 3.3 v118.2)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Received: by NeXT.Mailer (1.118.2)
Sender:ietf-request at ietf.org
From: Andy Mickel <andym at mr.net>
Date: Wed, 11 Jun 97 07:20:55 -0500
To: Quinton Jansen <qjansen at dns1.cent.org>
Subject: Java's year-2000-alike problem
Cc: ietf at ietf.org, fritchie at mr.net
Source-Info: From (or Sender) name not authenticated.
Found this in RISKS DIGEST volume 19.21:
>Date: Mon, 2 Jun 1997 13:09:01 -0700 (PDT)
>From: Quinton Jansen <qjansen at dns1.cent.org>
>To: ietf at ietf.org
>Subject: Java has a similar problem to the 2000-year problem
>
>"TIME IS ON JAVA'S SIDE (*Information Week*, 19 May 1997, p. 12)
>
>Sun Microsystems acknowledged last week that the Java programming language
>has a year-2000-like date error: It will run out of dates in the year
>292271023. Yes, that's roughly 292 million years from now. James Gosling,
>creator of Java, insists a team of engineers is rushing to fix the problem.
>"We can't be certain Java will be around that long," he kids, "but then
>again, we can't take any chances."
>
>In case you were wondering, the year 292271023 is the estimated date for the
>year 2000 fix at the IRS."
^^^
you misspelled "IBM"! What with OS/360 and DOS they should be taken to court
class-action-wise for perpetrating the problem (all in the name of profits,
no doubt!).
- Andy
--^~~,._ Andrew B. Mickel Telephone: +1-612/362-5831
| / Dir. Engineering & Tech Services FAX: +1-612/362-5899
| / Minnesota Regional Network E-mail: andym at mr.net
{ **{ <--(MRNet, Twin Cities) URL: http://www.mr.net/~andym/
|_____\ 2829 SE University Ave., #200 Minneapolis, MN 55414 USA
Received: from ietf.org by ietf.org id aa08510; 11 Jun 97 10:10 EDT
Received: from ietf.ietf.org by ietf.org id aa06740; 11 Jun 97 9:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: mboned at ns.uoregon.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-mboned-admin-ip-space-03.txt
Date: Wed, 11 Jun 1997 09:25:15 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706110925.aa06740 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 MBONE Deployment Working
Group of the IETF.
Title : Administratively Scoped IP Multicast
Author(s) : D. Meyer
Filename : draft-ietf-mboned-admin-ip-space-03.txt
Pages : 7
Date : 06/10/1997
This document defines the "administratively scoped IPv4 multicast space" to
be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a
simple set of semantics for the implementation of Administratively Scoped
IP Multicast. Finally, it provides a mapping between the IPv6 multicast
address classes [RFC1884] and IPv4 multicast address classes.
This memo is a product of the MBONE Deployment Working Group (MBONED) in
the Operational Requirements area of the Internet Engineering Task Force.
Submit comments to <mboned at ns.uoregon.edu> or the author.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mboned-admin-ip-space-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mboned-admin-ip-space-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mboned-admin-ip-space-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970610132438.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mboned-admin-ip-space-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mboned-admin-ip-space-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970610132438.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08487; 11 Jun 97 10:10 EDT
Received: from ietf.ietf.org by ietf.org id aa06791; 11 Jun 97 9:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipngwg-ipv6-tcp-mib-00.txt
Date: Wed, 11 Jun 1997 09:25:29 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706110925.aa06791 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 IPNG Working Group of the
IETF.
Title : IP Version 6 Management Information Base for the
Transmission Control Protocol
Author(s) : M. Daniele
Filename : draft-ietf-ipngwg-ipv6-tcp-mib-00.txt
Pages : 6
Date : 06/10/1997
This document is one in the series of documents that define various MIB
objects for IPv6. Specifically, this document is the MIB module which
defines managed objects for implementations of the Transmission Control
Protocol (TCP) over IP Version 6 (IPv6).
This document also recommends a specific policy with respect to the
applicability of RFC 2012 for implementations of IPv6. Namely, the most of
managed objects defined in RFC 2012 are independent of which IP versions
underly TCP, and only the TCP connection information is IP
version-specific.
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the IPv6-based
internets.
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-ipngwg-ipv6-tcp-mib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-tcp-mib-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tcp-mib-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970610133530.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tcp-mib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-ipv6-tcp-mib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970610133530.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08505; 11 Jun 97 10:10 EDT
Received: from ietf.ietf.org by ietf.org id aa06990; 11 Jun 97 9:26 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-hoffman-pkcs-certif-req-01.txt
Date: Wed, 11 Jun 1997 09:26:16 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706110926.aa06990 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : PKCS #10: Certification Request Syntax
Version 1.5
Author(s) : P. Hoffman
Filename : draft-hoffman-pkcs-certif-req-01.txt
Pages : 8
Date : 06/10/1997
This standard describes a syntax for certification requests.
Please note: The information in this document is historical material being
published for the public record. It is not an IETF standard. The use of
the word "standard" in this document indicates a standard for RSA
Laboratories and its customers, not an IETF 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-hoffman-pkcs-certif-req-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hoffman-pkcs-certif-req-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-hoffman-pkcs-certif-req-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970610152705.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hoffman-pkcs-certif-req-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hoffman-pkcs-certif-req-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970610152705.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08508; 11 Jun 97 10:10 EDT
Received: from ietf.ietf.org by ietf.org id aa06773; 11 Jun 97 9:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: mboned at ns.uoregon.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-mboned-imrp-some-issues-02.txt
Date: Wed, 11 Jun 1997 09:25:22 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706110925.aa06773 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 MBONE Deployment Working
Group of the IETF.
Title : Some Issues for an Inter-domain
Multicast Routing Protocol
Author(s) : D. Meyer
Filename : draft-ietf-mboned-imrp-some-issues-02.txt
Pages : 12
Date : 06/10/1997
The IETF's Inter-Domain Multicast Routing (IDMR) working group has produced
several multicast routing protocols, including Core Based Trees [CBT] and
Protocol Independent Multicasting [PIMARCH]. In addition, the IDMR WG has
formalized the specification of the Distance Vector Multicast Routing
Protocol [DVMRP]. Various specifications for protocol inter-operation have
also been produced (see, for example, [THALER96] and [PIMMBR]). However,
none of these protocols seems ideally suited to the inter-domain routing
case; that is, while these protocols are appropriate for the intra-domain
routing environment, they break down in various ways when applied in to the
multi-provider inter-domain case.
This document considers some of the scaling, stability and policy issues
that are of primary importance in a inter-domain, multi-provider
multicast environment.
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-mboned-imrp-some-issues-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mboned-imrp-some-issues-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mboned-imrp-some-issues-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970610132843.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mboned-imrp-some-issues-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mboned-imrp-some-issues-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970610132843.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08509; 11 Jun 97 10:10 EDT
Received: from ietf.ietf.org by ietf.org id aa06909; 11 Jun 97 9:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: find at bunyip.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-find-cip-trans-00.txt
Date: Wed, 11 Jun 1997 09:25:56 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706110925.aa06909 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Common Indexing Protocol
Working Group of the IETF.
Title : CIP Transport Protocols
Author(s) : J. Allen, P. Leach
Filename : draft-ietf-find-cip-trans-00.txt
Pages : 5
Date : 06/10/1997
This document specifies three protocols for transporting CIP requests,
responses and index objects, utilizing TCP, mail, and HTTP. The objects
themselves are defined in [CIP-MIME] and the overall CIP architecture is
defined in [CIP-ARCH].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-find-cip-trans-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-find-cip-trans-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-find-cip-trans-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970610142810.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-find-cip-trans-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-find-cip-trans-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970610142810.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08503; 11 Jun 97 10:10 EDT
Received: from ietf.ietf.org by ietf.org id aa07293; 11 Jun 97 9:35 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: agentx at fv.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-agentx-ext-pro-04.txt
Date: Wed, 11 Jun 1997 09:35:13 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706110935.aa07293 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 SNMP Agent Extensibility
Working Group of the IETF.
Title : Agent Extensibility (AgentX) Protocol Version 1
Author(s) : M. Daniele, B. Wijnen, D. Francisco
Filename : draft-ietf-agentx-ext-pro-04.txt
Pages : 81
Date : 06/10/1997
This memo defines a standardized framework for extensible SNMP agents. It
defines processing entities called master agents and subagents, a protocol
(AgentX) used to communicate between them, and the elements of procedure by
which the extensible agent processes SNMP protocol messages.
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-agentx-ext-pro-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-agentx-ext-pro-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-agentx-ext-pro-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970610153044.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-agentx-ext-pro-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-agentx-ext-pro-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970610153044.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08504; 11 Jun 97 10:10 EDT
Received: from ietf.ietf.org by ietf.org id aa06814; 11 Jun 97 9:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipngwg-ipv6-udp-mib-00.txt
Date: Wed, 11 Jun 1997 09:25:37 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706110925.aa06814 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 IPNG Working Group of the
IETF.
Title : IP Version 6 Management Information Base
for the User Datagram Protocol
Author(s) : M. Daniele
Filename : draft-ietf-ipngwg-ipv6-udp-mib-00.txt
Pages : 5
Date : 06/10/1997
This document is one in the series of documents that define various MIB
objects for IPv6. Specifically, this document is the MIB module which
defines managed objects for implementations of the User Datagram Protocol
(UDP) over IP Version 6 (IPv6).
This document also recommends a specific policy with respect to the
applicability of RFC 2013 for implementations of IPv6. Namely, the most
of managed objects defined in RFC 2013 are independent of which IP versions
underly UDP, and only the UDP listener information is IP version-specific.
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the IPv6-based
internets.
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-ipngwg-ipv6-udp-mib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-udp-mib-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipngwg-ipv6-udp-mib-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970610133927.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-ipv6-udp-mib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-ipv6-udp-mib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970610133927.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08491; 11 Jun 97 10:10 EDT
Received: from ietf.ietf.org by ietf.org id aa06935; 11 Jun 97 9:26 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-hoffman-pkcs-rsa-encrypt-01.txt
Date: Wed, 11 Jun 1997 09:26:08 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706110926.aa06935 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : PKCS #1: RSA Encryption Version 1.5
Author(s) : P. Hoffman
Filename : draft-hoffman-pkcs-rsa-encrypt-01.txt
Pages : 18
Date : 06/10/1997
This standard describes a method for encrypting data using the RSA
public-key cryptosystem.
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-hoffman-pkcs-rsa-encrypt-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hoffman-pkcs-rsa-encrypt-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-hoffman-pkcs-rsa-encrypt-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970610151905.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hoffman-pkcs-rsa-encrypt-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hoffman-pkcs-rsa-encrypt-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970610151905.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08506; 11 Jun 97 10:10 EDT
Received: from ietf.ietf.org by ietf.org id aa06701; 11 Jun 97 9:24 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipngwg-ipv6-mib-02.txt
Date: Wed, 11 Jun 1997 09:24:50 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706110924.aa06701 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 IPNG Working Group of the
IETF.
Title : Management Information Base for IP Version 6: Textual
Conventions and General Group
Author(s) : D. Haskin, S. Onishi
Filename : draft-ietf-ipngwg-ipv6-mib-02.txt
Pages : 41
Date : 06/10/1997
This document is one in the series of documents that provide MIB
definitions for IP Version 6. Specifically, the IPv6 MIB textual
conventions as well as the IPv6 MIB General group is defined in this
document.
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the IPv6-based
internets.
This document 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-ipngwg-ipv6-mib-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-mib-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipngwg-ipv6-mib-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970610131309.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-ipv6-mib-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-ipv6-mib-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970610131309.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08507; 11 Jun 97 10:10 EDT
Received: from ietf.ietf.org by ietf.org id aa06683; 11 Jun 97 9:24 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-zigmond-tv-url-00.txt
Date: Wed, 11 Jun 1997 09:24:45 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706110924.aa06683 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Uniform Resource Locators for Television Broadcasts
Author(s) : D. Zigmond
Filename : draft-zigmond-tv-url-00.txt
Pages : 3
Date : 06/10/1997
World-Wide Web browsers are starting to appear on a variety of consumer
electronic devices, such as television sets and television set-top boxes,
which are capable of receiving television programming from either
terrestrial broadcast, satellite broadcast, or cable. On these devices,
some of the URL schemes described in [1] are inappropriate. For example,
many of these devices lack local storage, so the "file" scheme is of little
use. This draft proposes a new URL scheme for uniquely identifying streams
of television broadcasts on such devices.
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-zigmond-tv-url-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-zigmond-tv-url-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-zigmond-tv-url-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970610153653.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-zigmond-tv-url-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-zigmond-tv-url-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970610153653.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08679; 11 Jun 97 10:10 EDT
Received: from ietf.ietf.org by ietf.org id aa08324; 11 Jun 97 10:04 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-exp-rupp-02.txt
Date: Wed, 11 Jun 1997 10:04:46 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706111004.aa08324 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Protocol for the Transmission of Net News Articles
over IP multicast.
Author(s) : H. Rupp
Filename : draft-rfced-exp-rupp-02.txt
Pages : 9
Date : 06/10/1997
This protocol provides a way to use the IP multicast infrastructure to
transmit NetNews articles between news servers. Doing so will reduce the
bandwidth that is actually needed for transmission via NNTP. This does not
affect how news reading clients communicate with servers.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-rfced-exp-rupp-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-exp-rupp-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-exp-rupp-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970610131735.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-exp-rupp-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-exp-rupp-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970610131735.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11363; 11 Jun 97 12:21 EDT
Received: from black-ice.cc.vt.edu by ietf.org id aa11247; 11 Jun 97 12:16 EDT
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.6.Beta3/8.8.6.Beta3) with ESMTP id MAA27104;
Wed, 11 Jun 1997 12:12:07 -0400
Message-Id: <199706111612.MAA27104 at black-ice.cc.vt.edu>
To: Andy Mickel <andym at mr.net>
Cc: ietf at ietf.org
Subject: Re: Java's year-2000-alike problem
In-Reply-To: Your message of "Wed, 11 Jun 1997 07:20:55 CDT."
<9706111220.AA01465 at eleventh>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <9706111220.AA01465 at eleventh>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1032468178P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Wed, 11 Jun 1997 12:12:06 -0400
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_1032468178P
Content-Type: text/plain; charset=us-ascii
On Wed, 11 Jun 1997 07:20:55 CDT, Andy Mickel said:
> you misspelled "IBM"! What with OS/360 and DOS they should be taken to court
> class-action-wise for perpetrating the problem (all in the name of profits,
> no doubt!).
If some mail gateway munched a smiley on this, hit "delete" now. ;)
OS/360 and DOS are long dead. OS/360 was essentially dead back in 1974 or so,
when VS/1 and VS/2 (later to become MVS) came out. IBM's current operating
system offerings (OS/390 Version 2, VM/ESA Version 2, VSE/ESA, and TPF) are
Y2K clean. The *REAL* problem with Y2K is site-maintained code - for instance,
Virginia Tech has some *OLD* IMS/COBOL code that has Y2K problems. However,
we have to migrate from MVS/XA (yes, we're ancient) to MVS/ESA to get the opsys
itself Y2K-clean - and then the ESA COBOL compiler won't compile the old code
because COBOL itself has changed. Oh.. did I mention we have some 6 million
lines of IMS transaction code?
It's hardly IBM's fault that we failed to allocate sufficient resources back
in 1970 to forestall failures in systems in 1999, when nobody even expected
the systems to be in USE in 1999. Sort of like suing an auto manufacturer
because your 1957 Chevy has problems meeting current emmissions standards...
Incidentally, IBM *was* taken to court regarding OS/360 and related issues
of hardware and software bundling.
For information on what IBM is *really* doing about the Y2K problem,
see http://www.software.ibm.com/year2000/
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
--==_Exmh_1032468178P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBM57OVNQBOOoptg9JAQG41AQAhwr4woOMNgWznhD1WN+joepg4gbb4kJI
ZRY8LG/1swdgwIuwyQDTkfCke9ZeNe1FV1CBZxBLpZlAjOqo6Y+GN8x9PUuDSR+U
icigRZbPO70llDyF/vdxom0J7o11WhlgJeJpLSaqcJWjU+c+2h8NWR8YEkS9NyY5
hLTa5sBfEb8=
=SKrY
-----END PGP MESSAGE-----
--==_Exmh_1032468178P--
Received: from ietf.org by ietf.org id aa14227; 11 Jun 97 13:36 EDT
Received: from denmark-c.it.earthlink.net by ietf.org id aa14110;
11 Jun 97 13:31 EDT
Received: from papa (pool018.max1.montebello.ca.us.dynip.earthlink.net [206.85.113.18])
by denmark.it.earthlink.net (8.8.5/8.8.5) with SMTP id KAA08084;
Wed, 11 Jun 1997 10:26:54 -0700 (PDT)
Message-Id: <3.0.32.19970611102513.009a1ea0 at earthlink.net>
X-Sender: rmonsour at earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 11 Jun 1997 10:25:15 -0700
To: Valdis.Kletnieks at vt.edu
Sender:ietf-request at ietf.org
From: Bob Monsour <rmonsour at hifn.com>
Subject: Re: Java's year-2000-alike problem
Cc: Andy Mickel <andym at mr.net>, ietf at ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
At 12:12 PM 6/11/97 -0400, Valdis.Kletnieks at vt.edu wrote:
>OS/360 and DOS are long dead. OS/360 was essentially dead back in 1974 or so,
^^^
I beg to differ that DOS is "long dead". It seems that many of the small
business outfits like small legal, health (dentist, doctor, etc.) and
accounting firms I walk in to have DOS database apps that do all their
client management and billing. I'm not intimately familiar to know whether
DOS has the year2000 problem or not, but if it does, there are a lot of
unsuspecting users out there.
-Bob
Received: from ietf.org by ietf.org id aa14888; 11 Jun 97 14:01 EDT
Received: from black-ice.cc.vt.edu by ietf.org id aa14791; 11 Jun 97 13:59 EDT
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.6.Beta3/8.8.6.Beta3) with ESMTP id NAA25324;
Wed, 11 Jun 1997 13:54:00 -0400
Message-Id: <199706111754.NAA25324 at black-ice.cc.vt.edu>
To: Bob Monsour <rmonsour at hifn.com>
Cc: Andy Mickel <andym at mr.net>, ietf at ietf.org
Subject: Re: Java's year-2000-alike problem
In-Reply-To: Your message of "Wed, 11 Jun 1997 10:25:15 PDT."
<3.0.32.19970611102513.009a1ea0 at earthlink.net>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <3.0.32.19970611102513.009a1ea0 at earthlink.net>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-2121162814P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Wed, 11 Jun 1997 13:53:59 -0400
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-2121162814P
Content-Type: text/plain; charset=us-ascii
On Wed, 11 Jun 1997 10:25:15 PDT, Bob Monsour said:
> I beg to differ that DOS is "long dead". It seems that many of the small
> business outfits like small legal, health (dentist, doctor, etc.) and
Not MS/Dos. DOS. We're talking IBM's software to drive low-end System/360
systems released in 1964. If they upgraded to a System/370, or 43xx processor,
they would have upgraded to DOS/VS. I think DOS/VSE was required for
30xx and 9xxx support, but I could be wrong. I'm sure that outside the
PRPQ S/360 and S/370 that the FAA is probably still using, they're about
as dead as Multics.
If you want to blame somebody for "the thing everybody calls DOS that runs
on Intel x86-based hardware", blame Microsoft. Or (urban legend time) blame
the guy who almost sold IBM on CP/M, but who chose to go hang-gliding instead.
Remember that MS/Dos started off life as 'QDOS' (Quick&Dirty Op System). It
was as much of a patch-up hack job as the x86 hardware design (Trivia: Why
does the x86 have only 4 useful registers? Because the Intel 8085 only had
4 registers, and the 8086/8088 were designed to allow machine-translation
of the assembler source code....)
Enough of a history lesson for today ;)
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
--==_Exmh_-2121162814P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBM57mNNQBOOoptg9JAQEBgQP/Tol4Mv9nkfdeuLfz43EkhQBots/mHPQ1
vNVSjF0+0Mo8mVUDIv6xX7EEwhcFIUXqVfZ2JziUkEOkPN25+thmzNcoMlDB2kJR
OM6QscLIg8BWRWlDvNvVSop7kYX9aJc1xMyY5T3i/exgc387GVkdQ5jCVPLJENs3
xj9rQhyi+vA=
=tzeW
-----END PGP MESSAGE-----
--==_Exmh_-2121162814P--
Received: from ietf.org by ietf.org id aa14975; 11 Jun 97 14:04 EDT
Received: from emout01.mx.aol.com by ietf.org id aa14915; 11 Jun 97 14:02 EDT
Received: (from root at localhost)
by emout01.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0)
id NAA21062;
Wed, 11 Jun 1997 13:54:49 -0400 (EDT)
Date: Wed, 11 Jun 1997 13:54:49 -0400 (EDT)
Sender:ietf-request at ietf.org
From: CraigSimon at aol.com
Message-ID: <970611135445_522130221 at emout01.mail.aol.com>
To: ietf at ietf.org
cc: vjokubaitis at attmail.com, vcerf at mci.net, newdom at ar.com,
signato at email.archlab.tuwien.ac.at
Subject: Re: ITU/ISOC/IETF
Source-Info: From (or Sender) name not authenticated.
May I add my two cents on the ITU/ISOC/IETF question?
I think the issue is not whether a more formal relationship with the ITU
somehow subordinates the IETF, but whether these developments will eventually
constrain the leverage of sovereign states.
It seems clear enough that there are attractive synergies for the ITU and
IETF (and WIPO, etc.) that can be achieved through the Gtld_MOU CORE concept.
As I understand it, the appeal tor people in IETF/ISOC and the IT industry,
is that the new structure would offer greater freedom from parochial
legislative concerns and associated political grandstanding. It provides a
way for the engineering-oriented individuals which lead the group to
harmonize their activities in a way that seems most rational to them. This
frees them to move forward with their technical projects. For officials in
the ITU and WIPO, it further legitimizes their activities as agents of
organizations which have historically sought explicitly global functions.
Both groups apparently share a vision of industrial self-regulation which
would make economic activity more independent of nation-state regulation and
interference.
The MOU may have large and lasting historical significance. It is interesting
to ask whether the ITU defines a long term vision for itself as an
intergovernmental organization, or as a primarily global one. If the latter,
that would explain why, immediately prior to the MOU signing ceremony in
Geneva, Madeline Albright allegedly complained about the ITU acting without
the consultation of member states. I'd be fascinated to hear an ITU
diplomat's response.
The industry's (and therefore ISOC's) desire for greater independence is
fairly straightforward. So, to me, a more interesting question is whether the
ITU is being transformed by this.
If so, the most obvious loser in this process may be the sovereign state, in
that the ITU is taking on responsibilities and making itself accountable to
other groups in ways which move states out of fundamental rule making
activities. But the losses for traditional governments are not necessarily so
great as to be unacceptable. Political gains are achievable, or at least the
perception of them. In the current global political climate, the leaders of
most industrialized countries states favor privatization, deregulation and
other "pro-competitive" forms of economic organization which foster increases
in gross measures of wealth. Since the telecommunications industry is so full
of promise, nearly every country has its own type of NII. The GII seems
uncontroversial, and almost universally popular. Therefore, more countries
are willing to bind themselves in what NYT journalist Anthony Lewis recently
called the "golden straitjacket." Less regulation promises more growth. (The
level of fairness in the delivery of that promise is another story.)
I would like to know the following:
1) After PSINet pulled out of the MOU signing, the company called for a
global conference on domain registration. What is happening with that? What
is ISOC's response?
2) My impression was that ITU and WIPO delgates had planned to sign the
document, but did not. Is this correct? What is the explanation?
3) Where can I find more about the activities of the PAB? I'm monitoring the
IAHC and related links, but I don't feel like I've found the treasure chest
of information with the inside scoop. Various journalists have touched on and
bits and pieces of this story. Where are their sources? (My interest in this,
by the way, is that I'm doing a dissertation on global standards making.)
4) Is the IETF list an appropriate place to talk about this stuff? If not,
exuse me. I'd happily take it somewhere else, but where?
Thanks
CraigSimon at shadow.net
CC: vjokubaitis at attmail.com
vcerf at mci.net
newdom at ar.com
signato at email.archlab.tuwien.ac.at
Received: from ietf.org by ietf.org id aa15256; 11 Jun 97 14:17 EDT
Received: from piraya.electrum.kth.se by ietf.org id aa15201;
11 Jun 97 14:15 EDT
Received: from drum.it.kth.se (drum.it.kth.se [130.237.213.23])
by piraya.electrum.kth.se (8.7.3/8.7.3) with ESMTP
id UAA29244;
Wed, 11 Jun 1997 20:10:17 +0200 (MET DST)
Message-Id: <199706111810.UAA29244 at piraya.electrum.kth.se>
To: rmonsour at hifn.com
Cc: Valdis.Kletnieks at vt.edu, andym at mr.net, ietf at ietf.org
Sender:ietf-request at ietf.org
From: Magnus Danielson <magda at it.kth.se>
Subject: Re: Java's year-2000-alike problem
In-Reply-To: Your message of "Wed, 11 Jun 1997 10:25:15 -0700"
References: <3.0.32.19970611102513.009a1ea0 at earthlink.net>
X-Mailer: Mew version 1.06 on Emacs 19.34.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Wed, 11 Jun 1997 20:10:16 +0200
X-Orig-Sender: e93_mda at drum.it.kth.se
Source-Info: From (or Sender) name not authenticated.
>>>>> "BM" == Bob Monsour <rmonsour at hifn.com> writes:
On a somewhat of topic discussion:
BM> At 12:12 PM 6/11/97 -0400, Valdis.Kletnieks at vt.edu wrote:
>> OS/360 and DOS are long dead. OS/360 was essentially dead back in 1974 or so,
BM> ^^^
BM> I beg to differ that DOS is "long dead". It seems that many of the small
BM> business outfits like small legal, health (dentist, doctor, etc.) and
BM> accounting firms I walk in to have DOS database apps that do all their
BM> client management and billing. I'm not intimately familiar to know whether
BM> DOS has the year2000 problem or not, but if it does, there are a lot of
BM> unsuspecting users out there.
I agree with Bob, don't forget that even thougth we learned to hate
DOS with passion it can still be quite enougth for a lot of tasks and
buissnesses. Graphical User Interfaces, windows, mouses, icons and all
that does not really beat functionallity and some of these systems
still has it. I still know of CP/M machines that with margin fullfill
their task.
Cheers,
Magnus
Received: from ietf.org by ietf.org id aa15884; 11 Jun 97 14:53 EDT
Received: from denmark-c.it.earthlink.net by ietf.org id aa15729;
11 Jun 97 14:45 EDT
Received: from papa (pool018.max1.montebello.ca.us.dynip.earthlink.net [206.85.113.18])
by denmark.it.earthlink.net (8.8.5/8.8.5) with SMTP id LAA05565;
Wed, 11 Jun 1997 11:41:28 -0700 (PDT)
Message-Id: <3.0.32.19970611113947.009a2b50 at earthlink.net>
X-Sender: rmonsour at earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 11 Jun 1997 11:39:50 -0700
To: "Valdis.Kletnieks at vt.edu" <Valdis.Kletnieks at vt.edu>
Sender:ietf-request at ietf.org
From: Bob Monsour <rmonsour at hifn.com>
Subject: Re: Java's year-2000-alike problem
Cc: Bob Monsour <rmonsour at hifn.com>, Andy Mickel <andym at mr.net>,
"ietf at ietf.org" <ietf at ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
Sorry, I thought you DID mean MS-DOS.
-Bob
At 10:53 AM 6/11/97 -0700, Valdis.Kletnieks at vt.edu wrote:
>On Wed, 11 Jun 1997 10:25:15 PDT, Bob Monsour said:
>> I beg to differ that DOS is "long dead". It seems that many of the small
>> business outfits like small legal, health (dentist, doctor, etc.) and
>
>Not MS/Dos. DOS. We're talking IBM's software to drive low-end
>System/360
>systems released in 1964. If they upgraded to a System/370, or 43xx
>processor,
>they would have upgraded to DOS/VS. I think DOS/VSE was required for
>30xx and 9xxx support, but I could be wrong. I'm sure that outside the
>PRPQ S/360 and S/370 that the FAA is probably still using, they're about
>as dead as Multics.
>
>If you want to blame somebody for "the thing everybody calls DOS that
>runs
>on Intel x86-based hardware", blame Microsoft. Or (urban legend time)
>blame
>the guy who almost sold IBM on CP/M, but who chose to go hang-gliding
>instead.
>
>Remember that MS/Dos started off life as 'QDOS' (Quick&Dirty Op System).
> It
>was as much of a patch-up hack job as the x86 hardware design (Trivia:
>Why
>does the x86 have only 4 useful registers? Because the Intel 8085 only
>had
>4 registers, and the 8086/8088 were designed to allow
>machine-translation
>of the assembler source code....)
>
>Enough of a history lesson for today ;)
>--
> Valdis Kletnieks
> Computer Systems Senior Engineer
> Virginia Tech
>
>
>
>
>Attachment Converted: "c:\program files\eudora\attach\ATT00100.att"
>
Received: from ietf.org by ietf.org id aa15905; 11 Jun 97 14:53 EDT
Received: from ftp.com by ietf.org id aa15837; 11 Jun 97 14:51 EDT
Received: from ftp.com by ftp.com ; Wed, 11 Jun 1997 14:44:14 -0400
Received: from mailserv-2high-a.ftp.com by ftp.com ; Wed, 11 Jun 1997 14:44:14 -0400
Received: by MAILSERV-2HIGH-A.FTP.COM (SMI-8.6/SMI-SVR4)
id OAA08456; Wed, 11 Jun 1997 14:46:29 -0400
Date: Wed, 11 Jun 1997 14:46:29 -0400
Message-Id: <199706111846.OAA08456 at MAILSERV-2HIGH-A.FTP.COM>
To: rmonsour at hifn.com
Subject: Re: Java's year-2000-alike problem
Sender:ietf-request at ietf.org
From: Craig Starr <cjs at ftp.com>
Reply-To: cjs at ftp.com
Cc: Valdis.Kletnieks at vt.edu, andym at mr.net, ietf at ietf.org
X-Orig-Sender: cjs at mailserv-2high-a.ftp.com
Repository: mailserv-2high-a.ftp.com, [message accepted at Wed Jun 11 14:46:27 1997]
Originating-Client: shostakovich.ftp.com
Source-Info: From (or Sender) name not authenticated.
> At 12:12 PM 6/11/97 -0400, Valdis.Kletnieks at vt.edu wrote:
> >OS/360 and DOS are long dead. OS/360 was essentially dead back in 1974 or so,
> ^^^
>
> I beg to differ that DOS is "long dead". It seems that many of the small
> business outfits like small legal, health (dentist, doctor, etc.) and
> accounting firms I walk in to have DOS database apps that do all their
> client management and billing. I'm not intimately familiar to know whether
> DOS has the year2000 problem or not, but if it does, there are a lot of
> unsuspecting users out there.
Correction please. Please look again at the context of this quote, noting
the reference to OS/360. DOS, in the context herein quoted, refers to
IBMs 30+ -year-old low-end operating system for its (mainframe) System/360,
which predates the Intel 8088 processor-based MS-DOS or PC-DOS (the context
I presume you are assuming) by at least 15 years. Its evolutionary path
progressed something like this: DOS, DOS/VS, DOS/VSE, VSE/SP, ???, VSE/ESA.
CJS
--
-----------------------------------------------------------------------------
Craig J. Starr FTP Software, Inc. Internet: cjs at ftp.com
Development 2 High Street
No. Andover, MA 01845 USA Voice: (508) 684-6481
-----------------------------------------------------------------------------
Good, fast, cheap: pick two.
Received: from ietf.org by ietf.org id aa17426; 11 Jun 97 16:15 EDT
Received: from ng.netgate.net by ietf.org id aa17294; 11 Jun 97 16:09 EDT
Received: from [205.214.161.17] (d52.netgate.net [205.214.160.86])
by ng.netgate.net (8.8.5/8.8.5) with ESMTP id NAA02003;
Wed, 11 Jun 1997 13:05:30 -0700 (PDT)
X-Sender:
Message-Id: <v04000220afc4aff0c161 at [205.214.161.17]>
In-Reply-To: <970611135445_522130221 at emout01.mail.aol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 11 Jun 1997 12:59:35 -0700
To: CraigSimon at aol.com
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at imc.org>
Subject: Re: ITU/ISOC/IETF
Cc: ietf at ietf.org, vjokubaitis at attmail.com, vcerf at mci.net, newdom at ar.com,
signato at email.archlab.tuwien.ac.at
Source-Info: From (or Sender) name not authenticated.
At 10:54 AM -0700 6/11/97, CraigSimon at aol.com wrote:
>1) After PSINet pulled out of the MOU signing, the company called for a
Sorry, but PSI didn't pull out. They were never part of the plan
for the signing and they did not participate in any of the months of
discussion, although they did participate in the very first press release.
>global conference on domain registration. What is happening with that? What
>is ISOC's response?
I can't imagine that ISOC will respond other than "we were given a
job and we did it; it doesn't need to be done (yet) again and the Interent
operational infrastructure doesn't need to suffer (yet more) delay."
>2) My impression was that ITU and WIPO delgates had planned to sign the
>document, but did not. Is this correct? What is the explanation?
No that is not correct. It was felt that their role made it
inappropriate to sign the document directly so, instead, they signed
letters supporting their role in the enabled structure.
>3) Where can I find more about the activities of the PAB? I'm monitoring the
>IAHC and related links, but I don't feel like I've found the treasure chest
As the PAB wishes to make information available, it will be under
the <http://www.gtld-mou.org> web page.
>4) Is the IETF list an appropriate place to talk about this stuff? If not,
>exuse me. I'd happily take it somewhere else, but where?
I belive the consensus view is that the ietf list is NOT
appropriate for any extended discussion of this topic.
d/
----------------------------
Dave Crocker, Director +1 408 246 8253
Internet Mail Consortium (f) +1 408 249 6205
675 Spruce Dr. dcrocker at imc.org
Sunnyvale, CA 94086 USA http://www.imc.org
Also: iPOC member, expressing personal opinions http://www.gtld-mou.org
Received: from ietf.org by ietf.org id aa18212; 11 Jun 97 16:54 EDT
Received: from proxy3.ba.best.com by ietf.org id aa18156; 11 Jun 97 16:52 EDT
Received: from [205.149.180.135] (boo.vip.best.com [205.149.180.135]) by proxy3.ba.best.com (8.8.5/8.8.3) with ESMTP id NAA09469 for <ietf at ietf.org>; Wed, 11 Jun 1997 13:44:10 -0700 (PDT)
X-Sender: boo at shell5.ba.best.com
Message-Id: <v0310280fafc4a9846350 at [205.149.180.135]>
In-Reply-To: <199706111754.NAA25324 at black-ice.cc.vt.edu>
References: Your message of "Wed, 11 Jun 1997 10:25:15 PDT."
<3.0.32.19970611102513.009a1ea0 at earthlink.net>
<3.0.32.19970611102513.009a1ea0 at earthlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Quote: I wasn't innocent till I got older. --WIK
X-Calibur: Signifying that I, Arthur, was to become King of the Britons
X-Mailer: Eudora Pro 3.1 for MacOS
Date: Wed, 11 Jun 1997 12:33:40 -0700
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Walter Ian Kaye <walter at natural-innovations.com>
Subject: Re: Java's year-2000-alike problem
Source-Info: From (or Sender) name not authenticated.
At 1:53p -0400 06/11/97, Valdis.Kletnieks at vt.edu wrote:
> If you want to blame somebody for "the thing everybody calls DOS that runs
> on Intel x86-based hardware", blame Microsoft. Or (urban legend time)
> blame the guy who almost sold IBM on CP/M, but who chose to go hang-gliding
> instead.
Urban legend = fantasy. Computer Chronicles, which used to be co-hosted by
Gary Kildall, did a tribute to him after he died. They explained that IBM
actually did supply both CP/M *and* DOS, but MS way undercut DR's price
(CP/M was priced at $240, while DOS was priced at $40). Since the public
at that time was not savvy to the superiority of DR's product, they saw no
reason to shell out 6x as much for it. Thus history was decided by wallets
instead of merits. The cruel part of it all was that Gary did not know
about the secret $40 deal, and had no opportunity to match the price. :/
As for me, I couldn't afford any computer until 1988, so IBoughtMacintosh. ;)
Now, as much fun as this has been, I don't think it belongs on ietf...
__________________________________________________________________________
Walter Ian Kaye <boo_at_best*com> Programmer - Excel, AppleScript,
Mountain View, CA ProTERM, FoxPro, HTML
http://www.natural-innovations.com/ Musician - Guitarist, Songwriter
Received: from ietf.org by ietf.org id aa18952; 11 Jun 97 17:30 EDT
Received: from excaliber.digitalink.com by ietf.org id aa18013;
11 Jun 97 16:44 EDT
Received: from mjolnir.digitalink.com by excaliber.digitalink.com; (5.65v3.0/1.1.8.2/15Jan96-0459PM)
id AA21349; Wed, 11 Jun 1997 16:39:14 -0400
Received: from vincewolodkin.digitalink.com by mjolnir.digitalink.com; (5.65v3.2/1.1.8.2/10Jan96-0415PM)
id AA23515; Wed, 11 Jun 1997 16:39:09 -0400
X-Orig-Sender: wolodkin at digitalink.com
Message-Id: <339F0BF7.50C9728F at digitalink.com>
Date: Wed, 11 Jun 1997 16:35:03 -0400
Sender:ietf-request at ietf.org
From: Vince Wolodkin <wolodkin at digitalink.com>
Organization: Digital Ink (Home of http://www.washingtonpost.com)
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.0 i586)
Mime-Version: 1.0
To: Dave Crocker <dcrocker at imc.org>
Cc: CraigSimon at aol.com, ietf at ietf.org, vjokubaitis at attmail.com,
vcerf at mci.net, newdom at ar.com, signato at email.archlab.tuwien.ac.at
Subject: Re: ITU/ISOC/IETF
References: <v04000220afc4aff0c161 at [205.214.161.17]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Dave Crocker wrote:
>
> At 10:54 AM -0700 6/11/97, CraigSimon at aol.com wrote:
> >3) Where can I find more about the activities of the PAB? I'm monitoring the
> >IAHC and related links, but I don't feel like I've found the treasure chest
>
> As the PAB wishes to make information available, it will be under
> the <http://www.gtld-mou.org> web page.
>
"As the PAB wishes to make information available"----Now this sounds
like a responsive group. One working on building consensus. Please oh
please let us know oh great one when you deem us capable of
understanding your great works.
> >4) Is the IETF list an appropriate place to talk about this stuff? If not,
> >exuse me. I'd happily take it somewhere else, but where?
>
> I belive the consensus view is that the ietf list is NOT
> appropriate for any extended discussion of this topic.
>
Dave's right, there is NO place appropriate for discussing this matter
because you simply are not invited to the discussion unless you sign the
MoU.
> d/
>
> ----------------------------
> Dave Crocker, Director +1 408 246 8253
> Internet Mail Consortium (f) +1 408 249 6205
> 675 Spruce Dr. dcrocker at imc.org
> Sunnyvale, CA 94086 USA http://www.imc.org
>
> Also: iPOC member, expressing personal opinions http://www.gtld-mou.org
Vince Wolodkin
Received: from ietf.org by ietf.org id aa19087; 11 Jun 97 17:34 EDT
Received: from alpha1.Reston.mci.net by ietf.org id aa18982; 11 Jun 97 17:30 EDT
Received: from dataarch1.bos.mci.net ([166.35.80.193])
by ALPHA1.RESTON.MCI.NET (PMDF V5.1-8 #8388)
with SMTP id <01IJYD8MYOXA0005XV at ALPHA1.RESTON.MCI.NET> for ietf at ietf.org;
Wed, 11 Jun 1997 17:26:18 EDT
Date: Wed, 11 Jun 1997 17:26:14 -0400 (Eastern Daylight Time)
Sender:ietf-request at ietf.org
From: John C Klensin <klensin at mci.net>
Subject: Re: Java's year-2000-alike problem
In-reply-to: <199706111754.NAA25324 at black-ice.cc.vt.edu>
To: Valdis.Kletnieks at vt.edu
Cc: Andy Mickel <andym at mr.net>, ietf at ietf.org,
Bob Monsour <rmonsour at hifn.com>
Reply-to: John C Klensin <klensin at mci.net>
Message-id: <SIMEON.9706111714.K at dataarch1.mci.net>
MIME-version: 1.0
X-Mailer: Simeon for Win32 Version 4.1.1 Build (14)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Priority: NORMAL
X-Authentication: none
Source-Info: From (or Sender) name not authenticated.
On Wed, 11 Jun 1997 13:53:59 -0400 Valdis.Kletnieks at vt.edu
wrote:
> I'm sure that outside the
> PRPQ S/360 and S/370 that the FAA is probably still using, they're about
> as dead as Multics.
"As dead as Multics" ??? Probably a bad analogy -- there
are a few still running and doing useful work. Given that
the total installed base was never huge, "a few" is a large
enough percentage that "dead as" is overrated.
But I continue to suspect that there are mainframes out
there somewhere that are emulating 1401s emulating 650s.
Some things *never* go away.
john
Received: from ietf.org by ietf.org id aa19209; 11 Jun 97 17:38 EDT
Received: from [207.32.128.74] by ietf.org id aa19158; 11 Jun 97 17:36 EDT
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by unir.corp (8.7.3/8.7.3) with SMTP id QAA08939; Wed, 11 Jun 1997 16:20:48 -0500 (CDT)
Received: by webster.unety.net with Microsoft Mail
id <01BC7684.774FA440 at webster.unety.net>; Wed, 11 Jun 1997 16:28:16 -0500
Message-ID: <01BC7684.774FA440 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: "CraigSimon at aol.com" <CraigSimon at aol.com>,
'Dave Crocker' <dcrocker at imc.org>
Cc: "ietf at ietf.org" <ietf at ietf.org>, "newdom at ar.com" <newdom at ar.com>,
"signato at email.archlab.tuwien.ac.at" <signato at email.archlab.tuwien.ac.at>,
"vcerf at mci.net" <vcerf at mci.net>,
"vjokubaitis at attmail.com" <vjokubaitis at attmail.com>
Subject: RE: ITU/ISOC/IETF
Date: Wed, 11 Jun 1997 16:28:15 -0500
Encoding: 107 TEXT
Source-Info: From (or Sender) name not authenticated.
On Wednesday, June 11, 1997 2:59 PM, Dave Crocker[SMTP:dcrocker at imc.org] wrote:
@ At 10:54 AM -0700 6/11/97, CraigSimon at aol.com wrote:
@ >1) After PSINet pulled out of the MOU signing, the company called for a
@
@ Sorry, but PSI didn't pull out. They were never part of the plan
@ for the signing and they did not participate in any of the months of
@ discussion, although they did participate in the very first press release.
@
Translation:
They were used to help develop credibility and then
were not needed. The IAHC went through people and
companies faster than a box of kleenex. NSI was also
part of the original press release and they obviously
did not support the outcome.
Most of the companies that support the outcome are
"brokers" that are already taking registrations (and money)
even though they have no name servers or infrastructure
installed.
Also, it is still not clear that the IAHC has made
arrangements to have the TLDs they want to support
entered into the legacy Root Name Servers that the U.S.
Government operates. PSI operates one of those servers.
NSI of course operates one as part of the InterNIC contract.
@ >global conference on domain registration. What is happening with that? What
@ >is ISOC's response?
@
@ I can't imagine that ISOC will respond other than "we were given a
@ job and we did it; it doesn't need to be done (yet) again and the Interent
@ operational infrastructure doesn't need to suffer (yet more) delay."
@
Translation:
Don Heath the CEO of the ISOC was the Chairperson
of the IAHC. He has quietly withdrawn from the situation.
George Strawn of the National Science Foundation has
also quietly withdrawn. Neither Heath or Strawn are on
the iPOC.
Sally Abel, one of the INTA attorneys has also quietly
bowed out of the process.
These people were used for credibility, but they clearly
do not want to be involved in this going forward. I suspect
they would not want to deal with the legal heat that may
come from being involved in that activity. Now that the
U.S. Government is involved, their decisions look very
wise. Some of the IAHC members have clearly stated
that their goal is to make sure that businesses do not
prosper in the Registry Industry. The FTC, the DOJ and
other agencies will likely have to get to the bottom of
those motivations.
@ >2) My impression was that ITU and WIPO delgates had planned to sign the
@ >document, but did not. Is this correct? What is the explanation?
@
@ No that is not correct. It was felt that their role made it
@ inappropriate to sign the document directly so, instead, they signed
@ letters supporting their role in the enabled structure.
@
Translation:
The ITU, WIPO and other agencies can make up whatever
rules they want. They, like Heath, Strawn and Abel are not
stupid. They have taken a convienant legal position that allows
them an out.
@ >3) Where can I find more about the activities of the PAB? I'm monitoring the
@ >IAHC and related links, but I don't feel like I've found the treasure chest
@
@ As the PAB wishes to make information available, it will be under
@ the <http://www.gtld-mou.org> web page.
@
Translation:
The PAB operates behind closed doors, just like the IAHC.
People are subject to their "wishes".
@ >4) Is the IETF list an appropriate place to talk about this stuff? If not,
@ >exuse me. I'd happily take it somewhere else, but where?
@
@ I belive the consensus view is that the ietf list is NOT
@ appropriate for any extended discussion of this topic.
@
Translation:
The less people talk about this the more the IAHC/iPOC
can claim there is consensus because they define
silence as consensus.
--
Jim Fleming
Unir Corporation
http://www.Unir.Corp
Received: from ietf.org by ietf.org id aa22132; 11 Jun 97 20:16 EDT
Received: from ng.netgate.net by ietf.org id aa21990; 11 Jun 97 20:11 EDT
Received: from [205.214.161.17] (d11.netgate.net [205.214.160.43])
by ng.netgate.net (8.8.5/8.8.5) with ESMTP id RAA01124;
Wed, 11 Jun 1997 17:07:07 -0700 (PDT)
X-Sender:
Message-Id: <v0400022aafc4db75fba2 at [205.214.161.17]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 11 Jun 1997 16:07:23 -0700
To: ietf at ietf.org, newdom at ar.com
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at imc.org>
Subject: Re: ITU/ISOC/IETF
Source-Info: From (or Sender) name not authenticated.
At 1:35 PM -0700 6/11/97, Vince Wolodkin wrote:
>please let us know oh great one when you deem us capable of
In your specific case, Vince, it's difficult to be sanguine about the
future. In any event, you are asking me as if you think that I have some
sort of control over PAB.
My point was that the PAB is it's own group and will act as it sees
fit. If you wish to submit comments to it, send them to
pab-submit at gtld-mou.org.
>Dave's right, there is NO place appropriate for discussing this matter
>because you simply are not invited to the discussion unless you sign the
>MoU.
I answered the question that was asked. Apparently there is some
broader interest in knowing a venue. For general discussion we've set up:
gtld-discuss at gtld-mou.org
which can be subscribed to by sending mail to
gtld-discuss-request at gtld-mou.org with the word subscribe in the body.
And Vince, thank you for playing.
d/
----------------------------
Dave Crocker, Director +1 408 246 8253
Internet Mail Consortium (f) +1 408 249 6205
675 Spruce Dr. dcrocker at imc.org
Sunnyvale, CA 94086 USA http://www.imc.org
Also: iPOC member, expressing personal opinions http://www.gtld-mou.org
Received: from ietf.org by ietf.org id aa07882; 12 Jun 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa07166; 12 Jun 97 9:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: find at bunyip.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-find-cip-arch-00.txt
Date: Thu, 12 Jun 1997 09:33:56 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706120933.aa07166 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Common Indexing Protocol
Working Group of the IETF.
Title : The Architecture of the Common Indexing Protocol (CIP)
Author(s) : J. Allen, M. Mealling
Filename : draft-ietf-find-cip-arch-00.txt
Pages : 11
Date : 06/11/1997
The Common Indexing Protocol (CIP) is used to pass indexing information
from server to server in order to facilitate query routing. Query routing
is the process of redirecting and replicating queries through a distributed
database system towards servers holding the desired results. This document
describes the CIP framework, including it's architecture and the protocol
specifics of exchanging indices.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-find-cip-arch-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-find-cip-arch-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-find-cip-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.
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: <19970611175057.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-find-cip-arch-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-find-cip-arch-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970611175057.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07883; 12 Jun 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa07135; 12 Jun 97 9:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-hamilton-dcxl-01.txt
Date: Thu, 12 Jun 1997 09:33:50 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706120933.aa07135 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Representing the Dublin Core within X.500,
LDAP and CLDAP
Author(s) : M. Hamilton, R. Iannella, J. Knight
Filename : draft-hamilton-dcxl-01.txt
Pages : 7
Date : 06/11/1997
The Dublin Core is a simple resource description format which arose out of
a loose grouping of "librarians, archivists, humanities scholars and
geographers, as well as standards makers in the Internet, Z39.50 and
Standard Generalized Markup Language (SGML) communities" [1].
This document describes a mapping from the abstract model of the Dublin
Core to the X.500 [2], LDAP [3], and CLDAP [4] directory service protocols.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-hamilton-dcxl-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hamilton-dcxl-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-hamilton-dcxl-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970611173750.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hamilton-dcxl-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hamilton-dcxl-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970611173750.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07888; 12 Jun 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa07098; 12 Jun 97 9:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: pwg at pwg.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-printmib-job-monitor-01.txt
Date: Thu, 12 Jun 1997 09:33:43 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706120933.aa07098 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 Printer MIB Working Group of
the IETF.
Title : Job Monitoring MIB - V0.82
Author(s) : R. Bergman, T. Hastings, S. Isaacson, H. Lewis
Filename : draft-ietf-printmib-job-monitor-01.txt
Pages : 92
Date : 06/11/1997
This Internet-Draft specifies a set of 17 SNMP MIB objects for (1)
monitoring the status and progress of print jobs (2) obtaining resource
requirements before a job is processed, (3) monitoring resource consumption
while a job is being processed and (4) collecting resource accounting data
after the completion of a job. This MIB is intended to be implemented (1)
in a printer or (2) in a server that supports one or more printers. Use of
the object set is not limited to printing. However, support for services
other than printing is outside the scope of this Job Monitoring MIB.
Future extensions to this MIB may include, but are not limited to, fax
machines and scanners.
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-printmib-job-monitor-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-printmib-job-monitor-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-printmib-job-monitor-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970611105831.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-printmib-job-monitor-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-printmib-job-monitor-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970611105831.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07885; 12 Jun 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa07117; 12 Jun 97 9:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ftp-wg at hops.ag.utk.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ftpext-feat-00.txt
Date: Thu, 12 Jun 1997 09:33:47 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706120933.aa07117 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 Extensions to FTP Working
Group of the IETF.
Title : Feature negotiation mechanism for the
File Transfer Protocol
Author(s) : P. Hethmon, R. Elz
Filename : draft-ietf-ftpext-feat-00.txt
Pages : 7
Date : 06/11/1997
The File Transfer Protocol is, from time to time, extended with new
commands, or facilities. Implementations of the FTP protocol cannot be
assumed to all immediately implement all newly defined mechanisms. This
document provides a mechanism by which clients of the FTP protocol can
discover which new features are supported by a particular FTP server.
This draft extracts the FEAT and OPTS commands from the "mlst" draft,
into this draft of their own. The descriptions of those commands have
been updated in an editorial way, no changes of substance have been made.
This paragraph will be deleted from the final version of this document.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ftpext-feat-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ftpext-feat-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ftpext-feat-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970611173231.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ftpext-feat-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ftpext-feat-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970611173231.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07887; 12 Jun 97 9:50 EDT
Received: from ietf.ietf.org by ietf.org id aa07079; 12 Jun 97 9:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: urn-ietf at bunyip.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-urn-resolution-services-01.txt
Date: Thu, 12 Jun 1997 09:33:37 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706120933.aa07079 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Names
Working Group of the IETF.
Title : URI Resolution Services Necessary for URN Resolution
Author(s) : M. Mealling, R. Daniel
Filename : draft-ietf-urn-resolution-services-01.txt
Pages : 8
Date : 06/11/1997
Fetching the resource identified by a Uniform Resource Identifier (URI) [3]
is only one of the operations that can be performed on a URI. We might ask
for a list of other identifiers that are aliases for the original URI, a
bibliographic description of the resource the URI denotes, etc. Because of
the diverse nature of resources on the network, it may be difficult (or
impossible) to offer all those operations, therefore a means of indicating
what services are and are not supported by a given resolver must be
specified. This memo gives an initial set of those operations, and the
requirements that must be met when those operations are encoded in a
protocol.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-urn-resolution-services-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-resolution-services-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-urn-resolution-services-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970611104939.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-urn-resolution-services-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-urn-resolution-services-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970611104939.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa10623; 12 Jun 97 10:24 EDT
Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid KAA14606; Thu, 12 Jun 1997 10:23:44 -0400 (EDT)
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <MAA01942 at pad-thai.cam.ov.com>; Thu, 12 Jun 1997 12:21:12 GMT
X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
Thu, 12 Jun 1997 14:19:56 +0200
X400-Received: by mta xn1-gw.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/;
Relayed; Thu, 12 Jun 1997 14:19:56 +0200
X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Thu, 12 Jun 1997 14:19:38 +0200
X400-Received: by /PRMD=sept/ADMD=ATLAS/C=FR/; Relayed;
Thu, 12 Jun 1997 07:11:37 +0200
Date: Thu, 12 Jun 1997 07:11:37 +0200
X400-Originator: eric.delacour at sept.fr
X400-Recipients: eric.delacour at cnet.francetelecom.fr, cat-ietf at mit.edu
X400-Mts-Identifier: [/PRMD=sept/ADMD=ATLAS/C=FR/;86614629790780000DELACOUR]
X400-Content-Type: P2-1984 (2)
Content-Identifier: UCOMX
Alternate-Recipient: Allowed
From: Eric DELACOUR <eric.delacour at sept.fr>
Message-Id: <86614629790780000DELACOUR*/G=eric/S=delacour/PRMD=sept/ADMD=ATLAS/C=FR/@MHS>
To: Non Receipt Notification Requested <cat-ietf at mit.edu>
Cc: eric delacour <eric.delacour at cnet.francetelecom.fr>
Subject: unsubscribe
Precedence: bulk
unsubscribe
Received: from ietf.org by ietf.org id aa11497; 12 Jun 97 10:29 EDT
Received: from ietf.ietf.org by ietf.org id aa11053; 12 Jun 97 10:26 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: rem-conf at es.net
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Protocol Action: RTP Payload Format for H.263 Video Streams to
Proposed Standard
Date: Thu, 12 Jun 1997 10:26:40 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706121026.aa11053 at ietf.org>
The IESG has approvedRTP Payload Format for H.263 Video Streams
<draft-ietf-avt-rtp-payload-03.txt> for publication as a Proposed
Standard.This document is the product of the Audio/Video Transport
Working Group. The IESG contact persons are Allyn Romanow and Scott
Bradner.
Technical Summary
This document descibes a scheme for packetizing an H.263 video stream
for transport using the Real-Time Transport Protocol (RTP, RFC1889).
H.263 video coding for low bitrate communication is defined by ITU-T
Recommendation H.263 and is widely used for video teleconferencing.
It builds on H.261, offering more options and a compressed encoding
which is more supportive of lower bitrates.
Three modes are defined for the H.263 payload header. An RTP packet
can use one of the three modes for H.263 video streams depending on
the desired network packet size and H.263 encoding options employed.
The shortest H.263 payload header (mode A) supports fragmentation at
Group of Block (GOB) boundaries. The long H.263 payload headers (mode
Ba dn C) support fragmentation at Macroblock (MB) boundaries.
Working Group Summary
There was no debate or controversy in the working group.
Protocol Quality
This document was reviewed for the IESG by Allyn Romanow.
Received: from ietf.org by ietf.org id aa13403; 12 Jun 97 10:41 EDT
Received: from ietf.ietf.org by ietf.org id aa12918; 12 Jun 97 10:37 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: Protocol Action: IMAP4 IDLE command to Proposed Standard
Date: Thu, 12 Jun 1997 10:37:33 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706121037.aa12918 at ietf.org>
The IESG has approved the Internet-Draft "IMAP4 IDLE command"
<draft-leiba-imap-idle-02.txt> as a Proposed Standard. This document
is not the product of an IETF Working Group. The IESG contact person
is Harald Alvestrand and Keith Moore.
Technical Summary
The IMAP4 basic protocol offers a limited asynchronous notification
facility: whenever the user does a command towards the server, the
server may tell the user of events that have occured, but only until
the command completes.
This extension introduces an IDLE command that lets the server go on
informing the user until the user declares itself no longer
interested; the typical usage will be that an IMAP client will
issue the IDLE command whenever it is not actively doing anything.
Working Group Summary
The protocol has been reviewed on the mailing list of the former
IMAP WG, and there was consensus that this was a good idea, and
that the spec is solid.
There were no Last Call objections and only one requested
clarification, which has been done.
Protocol Quality
The specification has been reviewed for the IESG by Harald Alvestrand
Received: from ietf.org by ietf.org id aa13692; 12 Jun 97 10:46 EDT
Received: from ietf.ietf.org by ietf.org id aa13491; 12 Jun 97 10:43 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: Internet Cache Protocol (ICP), version 2 to
Informational
Date: Thu, 12 Jun 1997 10:43:58 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706121043.aa13491 at ietf.org>
The IESG has reviewed the Internet-Draft "Internet Cache Protocol
(ICP), version 2" <draft-wessels-icp-v2-03.txt> and recommends that
it be published by the RFC Editor as an Informational RFC.
Received: from ietf.org by ietf.org id aa13902; 12 Jun 97 10:48 EDT
Received: from ietf.ietf.org by ietf.org id aa13708; 12 Jun 97 10:46 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
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-mib-08.txt
Date: Thu, 12 Jun 1997 10:46:23 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706121046.aa13708 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.
Note: This revision reflects comments received during the last call period.
Title : RSVP Management Information Base
Author(s) : F. Baker, J. Krawczyk
Filename : draft-ietf-rsvp-mib-08.txt
Pages : 83
Date : 06/12/1997
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing the Resource Reservation
Protocol (RSVP) within the interface attributes defined in the Integrated
Services Model. Thus, the Integrated Services MIB is directly relevant to
and cross-referenced by this MIB. Comments should be made to the RSVP
Working Group, rsvp at isi.edu.
This memo does not, in its draft form, specify a standard for
the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rsvp-mib-08.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-mib-08.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rsvp-mib-08.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
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: <19970612101335.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rsvp-mib-08.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-mib-08.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970612101335.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13949; 12 Jun 97 10:48 EDT
Received: from ietf.ietf.org by ietf.org id aa13725; 12 Jun 97 10:46 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
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-mib-07.txt
Date: Thu, 12 Jun 1997 10:46:25 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706121046.aa13725 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.
Note: This revision reflects comments received during the last call period.
Title : Integrated Services Management Information Base
Author(s) : F. Baker, J. Krawczyk
Filename : draft-ietf-intserv-mib-07.txt
Pages : 29
Date : 06/12/1997
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing the the interface attributes
defined in the Integrated Services Model. Comments should be made to the
Integrated Services Working Group, int-serv at isi.edu.
This memo does not, in its draft form, specify a standard
for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-intserv-mib-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-intserv-mib-07.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-intserv-mib-07.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970612101048.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-intserv-mib-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-intserv-mib-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970612101048.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15024; 12 Jun 97 10:57 EDT
Received: from ietf.ietf.org by ietf.org id aa14886; 12 Jun 97 10:54 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: idmr at cs.ucl.ac.uk
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Document Action: Core Based Trees (CBT) Multicast Routing
to Experimental
Date: Thu, 12 Jun 1997 10:54:55 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706121054.aa14886 at ietf.org>
The IESG has reviewed the following Internet-Drafts and recommend
they be published by the RFC Editor as an Experimental RFCs:
1. Core Based Trees (CBT) Multicast Routing Architecture
<draft-ietf-idmr-cbt-arch-06.txt> and
2. Core Based Trees (CBT Version 2) Multicast Routing Protocol
Specification <draft-ietf-idmr-cbt-spec-09.txt>
These documents are the product of the Inter-Domain Multicast Routing
Working Group. The IESG contact person is Joel Halpern.
Received: from ietf.org by ietf.org id aa17882; 12 Jun 97 11:35 EDT
Received: from ietf.ietf.org by ietf.org id aa17807; 12 Jun 97 11:33 EDT
To: IETF-Announce: ;
cc: receipt at cs.utk.edu
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: An Extensible Message Format for Message Disposition
Notifications to Proposed Standard
Reply-to: iesg at ietf.org
Date: Thu, 12 Jun 1997 11:33:07 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706121133.aa17807 at ietf.org>
The IESG has received a request from the Receipt Notifications for
Internet Mail Working Group to consider "An Extensible Message Format
for Message Disposition Notifications" <draft-ietf-receipt-mdn-03.txt>
for the status of Proposed Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by June 26, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa18340; 12 Jun 97 11:54 EDT
Received: from zephyr.isi.edu by ietf.org id aa18181; 12 Jun 97 11:47 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
id <AA22662>; Thu, 12 Jun 1997 08:43:27 -0700
Message-Id: <199706121543.AA22662 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: STD 1, RFC 2200 on Internet Standards
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 12 Jun 97 08:43:27 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.
STD 1:
RFC 2200:
Title: INTERNET OFFICIAL PROTOCOL STANDARDS
Author: Internet Architecture Board
J. Postel, Editor
Date: June 1997
Mailbox: Postel at ISI.EDU
Pages: 39
Characters: 94506
Obsoletes: 2000, 1920, 1880, 1800, 1780,1720, 1610, 1600,
1540, 1500, 1410, 1360,1280, 1250, 1200, 1140,
1130, 1100, 1083
URL: ftp://ds.internic.net/rfc/rfc2200.txt
This memo describes the state of standardization of protocols used in
the Internet as determined by the Internet Architecture Board (IAB).
This memo is an Internet Standard. Distribution of this memo is
unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970612083009.RFC at ISI.EDU>
SEND /rfc/rfc2200.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2200.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970612083009.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19300; 12 Jun 97 12:23 EDT
Received: from ietf.ietf.org by ietf.org id aa19192; 12 Jun 97 12:21 EDT
To: IETF-Announce at ietf.org
cc: all-ietf at ietf.org
Subject: WG ACTION: Mobile Ad-hoc Networks (manet)
Date: Thu, 12 Jun 1997 12:21:44 -0400
Sender:ietf-announce-request at ietf.org
From: Cynthia Clark <cclark at ietf.org>
Message-ID: <9706121221.aa19192 at ietf.org>
A new working group has been formed in the Routing Area
of the IETF. For additional information, contact the Area Directors
or the WG Chair.
Mobile Ad-hoc Networks (manet)
------------------------------
Chair(s):
Scott Corson <corson at isr.umd.edu>
Joseph Macker <macker at itd.nrl.navy.mil>
Routing Area Director(s):
Joel Halpern <jhalpern at newbridge.com>
Mailing lists:
General Discussion:manet at itd.nrl.navy.mil
To Subscribe: majordomo at itd.nrl.navy.mil
In Body: subscribe manet
Archive:
Description of Working Group:
A "mobile ad-hoc network" is an autonomous system of mobile routers (and
associated hosts) connected by wireless links--the union of which form an
arbitrary graph. The routers are free to move randomly and organize
themselves arbitrarily; thus, the network's wireless topology may change
rapidly and unpredictably. Such a network may operate in a standalone
fashion, or may be connected to the larger Internet.
The focus of the working group will be to standardize an intra-domain
unicast routing protocol which efficiently reacts to topological changes
while maintaining effective routing. The goal is to support networks
scaling up to hundreds of routers. If this proves successful, future work
may include development of other protocols to support additional routing
functionality.
The working group will examine the security issues around this protocol.
They will consider the intended usage environments, and the threats that
are (or are not) meaningful within that environment.
Goals and Milestones:
Jul 97 Post as an informational Internet-Drafts a discussion of mobile
ad-hoc networking and issues.
Aug 97 Obtain early performance results for the protocols
Dec 97 Implement the various protocols and test
Apr 98 Reach consensus on a mobile, ad-hoc unicast routing protocol.
Jul 98 Document mobile ad-hoc routing protocol and submit to the IESG
as a proposed standard, including security threat analysis.
Received: from ietf.org by ietf.org id aa19643; 12 Jun 97 12:39 EDT
Received: from ietf.ietf.org by ietf.org id aa19572; 12 Jun 97 12:36 EDT
To: IETF-Announce: ;
Subject: IETF-MUNICH: INTRODUCTION
Date: Thu, 12 Jun 1997 12:36:29 -0400
Sender:ietf-announce-request at ietf.org
From: Marcia Beaulieu <mbeaulie at ietf.org>
Message-ID: <9706121236.aa19572 at ietf.org>
Dear IETFers:
Following this message, you will receive three more regarding:
IETF REGISTRATION INFORMATION
AT-A-GLANCE
AGENDA
The following information is/will be available via the Web.
Agenda
At-A-Glance
Registration Information
Registration Form
Miscellaneous:
shipping information
directions
WG and BOF Agendas
Tao: Guide for New Attendees
WWW
-----
<http://www.ietf.org> Click on the link for "meetings" and you will
find an entry for the Munich, Germany meeting.
The following information is available via the remote directories:
Agenda
At-A-Glance
Registration Form
Tao: Guide for New Attendees
Travel Directions
FTP
-----
IETF Information is available by anonymous FTP from several sites.
US East Coast Address: ds.internic.net (198.49.45.10)
US West Coast Address: ftp.isi.edu (128.9.0.32)
Europe Address: nic.nordu.net (192.36.148.17)
Pacific Rim Address: munnari.oz.au (128.250.1.21)
cd ietf
ls *0mtg*
NOTE: Though we'd prefer to have payment of the meeting fee as soon
as possible, we definitely want immediate notification that you are
planning on coming. So, even though you know that payment will be
delayed for one reason or another, SEND THE RSVP FORM IN ANYWAY.
Received: from ietf.org by ietf.org id aa19752; 12 Jun 97 12:42 EDT
Received: from ietf.ietf.org by ietf.org id aa19686; 12 Jun 97 12:40 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: ietf-registrar at ietf.org
Subject: IETF-MUNICH: REGISTRATION INFORMATION
Date: Thu, 12 Jun 1997 12:40:32 -0400
X-Orig-Sender: mbeaulie at ietf.org
Message-ID: <9706121240.aa19686 at ietf.org>
On-line Registration & Payment Procedure
On-line Registration Procedure is now in effect, along with
a New Payment Schedule - Please Take Note!
Due to the increased number of attendees at IETF meetings, automating the
registration process has become a priority for the Secretariat. In doing so,
we have created an On-line Registration Form, accessible via the IETF
Web Home Page, making it easy and simple for you to register on-line!
Simply fill out the On-line Registration form completely and click on the
"Submit" button at the bottom of the page. If you forgot to fill out a
certain section, you will immediately receive a reply asking for that
information and you may re-submit your form. Please be sure that all
information you provide is correct!
You will then see an acknowledgement page on your browser listing the
information you just provided. If you need to make a change, please
contact the IETF Registrar at: ietf-registrar at ietf.org.
Your registration/confirmation number will come to you via e-mail, which
you should receive within 24 hours of submitting your registration form.
Please be sure to use this number for any future correspondence regarding
your registration.
The e-mail message will list your options for payment - 1) reply e-mail
using PGP, 2) print & fax, 3) print & mail ( additional on-line options are
planned for the future). You may choose whichever option is most
convenient for you.
NOTE: Your payment of US$325 must be RECEIVED by the cut-off date of
31 July 1997 in order for you to qualify for the lower registration fee.
If your payment is Not Received by the cut-off date, the fee will increase to
US$375 and must be paid on-site.
PLEASE BE SURE TO NOTE THIS NEW PAYMENT SCHEDULE!
You can view the Munich Meeting home page at:
http://www.ietf.org/meetings/Munich.html
The URL for the on-line registration form is:
http://www.ietf.org/meetings/reg_form.html
If you are unable to access our Home Page on the Web, or if you have any
questions regarding the new registration/payment procedure, please contact
the IETF Registrar at: ietf-registrar at ietf.org
Received: from ietf.org by ietf.org id aa19946; 12 Jun 97 12:48 EDT
Received: from ietf.ietf.org by ietf.org id aa19823; 12 Jun 97 12:45 EDT
To: IETF-Announce: ;
Subject: IETF-MUNICH: AT-A-GLANCE
Date: Thu, 12 Jun 1997 12:45:06 -0400
Sender:ietf-announce-request at ietf.org
From: Marcia Beaulieu <mbeaulie at ietf.org>
Message-ID: <9706121245.aa19823 at ietf.org>
39th INTERNET ENGINEERING TASK FORCE Date: June 12, 1997
AT-A-GLANCE
DATES: August 11-15, 1997 HOST:
ISOC.DE
ietf39 at isoc.de
HOTEL/MEETING SITE: The Sheraton Munich
Arabellastr. 6
Munich, Germany D-81925
Phone: 49 89 9264-0
{fax: 49 89 916877}
You need to contact the hotel directly, do not use
the USA central reservation system
CI 1600; CO 11:00
300 Rooms reserved until Monday, July 14, 1997.
Single: DM 185.00
Double: DM 210.00
(All rates include a daily American Breakfast Buffet)
Specify: IETF Group
ADDITIONAL ACCOM. Arabella Hotel Bogenhausen, Munich
Arabellstra. 5
81925 Munich
Tel: 49-89-92 32-0
Fax: 49-89-92-32-44 49
Specify: IETF Group
Block of 100 rooms (over dates of August 8-16, 1997)
reserved until July 18, 1997
Single: DM 190.00 inclusive of tax and breakfast
Double: DM 230.00 inclusive of tax and breakfast
Arabella Hotel is located across the street from
the Sheraton.
Hotel Rothof Bogenhausen, Munich
Denningerstr. 114
81925 Munich
Tel: 49-89-91-50-61
Fax: 49-89-91-50-66
Prefers reservations made by fax.
Specify: IETF Group
Block of 25 rooms (over dates of August 8-16, 1997)
reserved until July 8, 1997
Single: DM 216.00 (weekday); DM 158.00 (weekend)
Double: DM 278.00 (weekday); DM 198.00 (weekend)
(All rates inclusive of tax and breakfast)
Hotel Rothof is about an 8 minute walk from the Sheraton.
Queens Hotel, Munich
Effnerstr. 99
81925 Munich
Tel: 49-89-92-79-80
Fax: 49-89-98-38-13
Specify: IETF Group
Block of 50 rooms (over dates of August 8-16, 1997)
reserved until July 18, 1997
Single: DM 185.00 inclusive of tax and breakfast
Double: DM 210.00 inclusive of tax and breakfast
Please use fax form below to make your reservation.
Queens Hotel is about a 10 minute walk from the Sheraton.
The hotel also offer guests a complimentary shuttle
service to the Arabellapark where the Sheraton Hotel
is located, service is only Monday-Friday.
To: Queens Hotel Munchen
EffnerstraBe 99
81925 Munchen
Heike Haage - Reservation
Fax: 49-89-98-38-13
From: ___________________________________
Address: ___________________________________
___________________________________
Phone/Fax: ___________________________________
Ref: IETF (Internet Engineering Task Force) - August 1997
Phone/Fax: ___________________________________
Ref: IETF (Internet Engineering Task Force) - August 1997
Please reserve Name: _______________________________
Date: _______________________________
_____ DM 185,-- Single room/breakfast included
per night
_____ DM 210,-- Double room/breakfast included
per night
Arrival: _____ before 6:00 PM
_____ after 6:00 PM - reservation is guaranteed
Credit card: Number: ______________________
Type: ________________________
Expiration Date: _____________
NEWCOMER'S Sunday, August 10, 1997
ORIENTATION: 15:30 - 16:30
The Sheraton Munich
Room: Gallery Room
PRE-REGISTRATION: Sunday, August 10, 1997
17:00 - 19:00 (reception)
The Sheraton Munich
Room: Congress Hall
REGISTRATION: Monday, August 11, 1997
and BREAKS 08:00 - 18:00
Tuesday, August 12 - Thursday, August 14, 1997
08:30 - 18:00
Friday, August 15, 1997
08:30 - 12:00
The Sheraton Munich
Room: Congress Foyer
TERMINAL ROOM: Hall Munich
REGISTRATION FEE: The resgistration fee is US$325.00 if received by
the cut-off date of: 31 July 1997.
After this date, a fee of US$375.00 must be paid
on-site, whether or not you have pre-registered.
PAYMENT BY: Credit Card or Check
Received: from ietf.org by ietf.org id aa19947; 12 Jun 97 12:48 EDT
Received: from ietf.ietf.org by ietf.org id aa19858; 12 Jun 97 12:46 EDT
To: IETF-Announce: ;
Subject: IETF-MUNICH: AGENDA
Date: Thu, 12 Jun 1997 12:46:37 -0400
Sender:ietf-announce-request at ietf.org
From: Marcia Beaulieu <mbeaulie at ietf.org>
Message-ID: <9706121246.aa19858 at ietf.org>
****39th IETF: August 11-15, 1997/Munich, Germany****
PLEASE NOTE THE FOLLOWING:
1. NEWCOMER's ORIENTATION: On Sunday, August 10th at 1530 we will be
holding an orientation session for Newcomers (Room: Gallery)
ALL FIRST TIME ATTENDEES ARE ENCOURAGED TO READ RFC 1718 BEFORE
ATTENDING THE MEETING. Entitled "The Tao of IETF: A Guide for New
Attendees of the Internet Engineering Task Force", this RFC is available
by anonymous FTP, although an updated version is available via the
WEB.
2. PRE-REGISTRATION and a RECEPTION will be held on Sunday, August 10th
from 1700 - 1900 (Room: Congress Hall AB).
3. A Working Group Chairs Workshop will be held during lunch on Monday,
August 11th at 1130. Anyone interested in learning about the role of
the working group chair is welcome to attend. Location: TBD.
4. The Agenda below is a DRAFT and therefore subject to frequent changes.
We do not advise you use it to determine travel arrangements.
--------
FYI.....
A reminder that the quality of these meetings (and in particular the
Working Group technical *working* sessions) is dependent upon the
informed, constructive participation of the individual attendees. Please
come prepared.
Information on the current status and progress of the individual
Working Groups can be obtained in several ways:
1. Working Group objectives and notes from previous sessions are
available online (send to ietf-info at ietf.org for retrieval
instructions).
2. Working Group objectives and notes from previous meetings are
also reproduced in the hardcopy Proceedings (to order, send to
proceedings at ietf.org).
3. Agendas and reading lists for Working Group meetings will also be
posted to the respective Working Group mailing lists. And when
submitted to the Secretariat will be made available via the web.
IF YOU HAVE QUESTIONS REGARDING THE SCHEDULING OF A PARTICULAR WORKING
GROUP, PLEASE CONTACT THE CHAIR OF THAT GROUP DIRECTLY. A LISTING OF
WORKING GROUP MAILING LISTS IS AVAILABLE VIA ANONYMOUS FTP, CD IETF,
GET "1wg-summary.txt".
LOOKING AHEAD....
Information on future IETF meetings is available from the FTP Directories.
Look under filename "0mtg-sites.txt".
Draft Agenda of the Thirty-ninth IETF
(August 11-15, 1997)
As of June 10, 1997
MONDAY, August 11, 1997
0800-0900 IETF Registration and Continental Breakfast
0900-0930 Introductions
0930-1130 Morning Sessions
OPS roamops Roaming Operations WG
RTG idr Inter-Domain Routing WG
TSP tcpsat TCP Over Satellite BOF
1130-1300 Break
1300-1500 Afternoon Sessions I
INT ion Internetworking over NBMA WG
OPS disman Distributed Management WG
SEC tls Transport Layer Security WG
TSV ippm IP Performance Metrics BOF
USV uswg User Services WG
1500-1530 Break (Refreshments provided)
1530-1730 Afternoon Sessions II
INT ion Internetworking over NBMA WG
OPS roamops Roaming Operations WG
SEC spki Simple Public Key Infrastructure WG
1730-1930 Break
1930-2200 Evening Sessions
OPS snmpv3 SNMP Version 3 WG
RTG udlr Unidirectional Link Routing WG
SEC cat Common Authentication Technology WG
TUESDAY, August 12, 1997
0830-0900 Continental Breakfast
0900-1000 Morning Sessions I
1015-1115 Morning Sessions II
1115-1300 Break
1300-1400 Afternoon Sessions I
1415-1515 Afternoon Sessions II
1515-1545 Break (Refreshments provided)
1545-1645 Afternoon Sessions III
RTG mobileip IP Routing for Wireless/Mobile Hosts WG
1700-1800 Afternoon Sessions IV
RTG mobileip IP Routing for Wireless/Mobile Hosts WG
WEDNESDAY, August 13, 1997
0830-0900 Continental Breakfast
0900-1130 Morning Sessions
OPS ptopomib Physical Topology MIB WG
RTG mpls Multiprotocol Label Switching WG
SEC secsh Secure Shell WG
1130-1300 Break
1300-1500 Afternoon Sessions I
INT ippcp IP Payload Compression Protocol
OPS mboned MBONE Deployment WG
SEC pkix Public-Key Infrastructure (X.509) WG
1500-1530 Break (Refreshments provided)
1530-1730 Afternoon Sessions II
OPS snmpv3 SNMP Version 3 WG
RTG mpls Multiprotocol Label Switching WG
SEC cat Common Authentication Technology WG
1730-1930 Break
1930-2200 Evening Sessions
GEN iab Internet Architecture Board
OPS mboned MBONE Deployment WG
THURSDAY, August 14, 1997
0830-0900 Continental Breakfast
0900-1130 Morning Sessions
OPS rps Routing Policy System WG
RTG mobileip IP Routing for Wireless/Mobile Hosts WG
SEC pkix Public-Key Infrastructure (X.509) WG
1130-1300 Break
1300-1500 Afternoon Sessions I
OPS ptopomib Physical Topology MIB WG
RTG qosr QoS Routing WG
SEC saag Open Security Area Advisory Group
TSV rtfm Realtime Traffic Flow Measurement WG
1500-1530 Break (Refreshments provided)
1530-1630 Presentations
1630-1800 Open Plenary and IESG
FRIDAY, August 15, 1997
0830-0900 Continental Breakfast
0900-1130 Morning Sessions
Multicast sessions are in BOLD
Key to Abbreviations
APP Applications Harald Alvestrand/UNINETT and
Keith Moore/UTK
GEN General Interest Fred Baker/Cisco Systems
INT Internet Jeffrey Burgan/@Home Network and
Thomas Narten/IBM Corporation
OPS Operations & Management John Curran/BBN Corporation and
Michael O'Dell/UUNET Technologies
RTG Routing Joel Halpern/Newbridge Networks
SEC Security Jeff Schiller/MIT
TSV Transport Scott Bradner/Harvard University and
Allyn Romanow/Sun Microsystems
USV User Services Joyce K. Reynolds/ISI
Received: from ietf.org by ietf.org id aa20634; 12 Jun 97 13:27 EDT
Received: from njau.nj.mt.np.els-gms.att.net by ietf.org id aa20543;
12 Jun 97 13:24 EDT
Date: Thu, 12 Jun 1997 13:12:55 -0500
Sender:ietf-request at ietf.org
From: Vito Peter Jokubaitis <vjokubaitis at attmail.com>
Received: from vjokubaitis by attmail; Thu Jun 12 17:18:58 GMT 1997
Phone: +1 908 580 4283
Fax-Phone: +1 908 580 6881
Subject: RE: ITU/ISOC/IETF
To: ietf at ietf.org, JimFleming at unety.net, hsilbiger at exit109.com,
vcerf at mci.net
Cc: newdom at ar.com
X-MAPI-Message-ID: 00000000F86993E0F444CF11A85400AA0059C232648C3100
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-ID: <AW300MP000-vjokubaitis-47>
Source-Info: From (or Sender) name not authenticated.
We're getting into arcana here, but it's probably a good idea to air the =
matter. Three separate topics have been the subject of several messages.=
Taking them one by one:
MEMBERSHIP: The =22little m=22 designation refers to non-governmental (i=
.e., private sector) members of the ITU Sectors (e.g., AT&T and MCI are =22=
little m=22 members of the ITU-T). Only governments can be =22Big M=22 M=
embers of the ITU (and of its Sectors). The =22little m=22 designation i=
s proposed to be changed to =22Sector Member,=22 but this action is still=
pending. The ITU Council admitted ISOC to =22little m=22 membership in =
the ITU Sectors (where the real technical work gets done anyway), not the=
ITU, in 1995.
EXCHANGE OF INFORMATION: Regarding communications between the ITU-T Stud=
y Groups and the IETF, an ITU-T Recommendation A.4, entitled =22Communica=
tion Process between ITU-T and Forums and Consortia,=22 was approved by t=
he World Telecommunications Standards Conference (WTSC) of the ITU-T on 1=
0/19/96. This process includes a procedure for qualifying a forum or con=
sortium before establishment of a liaison relationship with the ITU-T; th=
e procedure addresses questions like the openness of the forum's or conso=
rtium's standardization process. The qualification procedure was used du=
ring the last so-called study period of the ITU-T (1993-1996) to qualify,=
for example, the ATM Forum. When I checked with the Chief Counsellor of=
the ITU-T very recently, I discovered that the IETF has not been qualifi=
ed under Recommendation A.4. He expressed the view that there was no nee=
d to do so, since he believed that any input to the ITU-T from the IETF c=
ould be made in the form of a contribution (roughly equivalent to an Inte=
rnet-Draft in IETF terminology) whose source would be the ISOC. After we=
got off the phone, it occurred to me that a few liaison statements have =
gone in both directions between IETF working groups and ITU-T Study Group=
s, which is a strange way of operating, since you don't normally communic=
ate with one of your own members by liaison statement. On the one hand i=
t looks like the ITU-T is treating IETF as a member and on the other hand=
as a standards forum.
REFERENCING OF DOCUMENTS: As for reference to IETF RFCs, a draft new ITU=
-T Recommendation A.xx, entitled =22Generic Procedures for Including Refe=
rences to Documents of Other Organizations in ITU-T Recommendations,=22 i=
s expected to undergo final approval in January 1998. There is a normat=
ive annex to this draft new Recommendation that is entitled =22Informatio=
n Specific to ISOC/IETF Documents.=22 So, the ITU-T has drafted a method=
for inclusion of RFCs as referenced documents in ITU-T Recommendations.=
Why should any of this matter, anyway? Well, it shouldn't surprise anyon=
e that there's an impedance mismatch between the ITU and the ISOC/IETF, a=
t least in the way the two organizations operate. While an understanding=
of some of the finer points of the relationship between the two organiza=
tions, as outlined above, may not help significantly to mitigate the diff=
erences, I've never known a situation in which persistent misperceptions =
have had positive effects. I, for one, am encouraged by the efforts to b=
ring the two organizations, each preeminent in its respective area, produ=
ctively together.
Vito P. Jokubaitis
----------
From: =09vinton g. cerf
Sent: =09Monday, June 09, 1997 12:12 PM
To: =09Vito Peter Jokubaitis; internet=21ietf.org=21ietf; internet=21unet=
y.net=21JimFleming; internet=21exit109.com=21hsilbiger
Cc: =09internet=21ar.com=21newdom
Subject: =09RE: ITU/ISOC/IETF
Herman is not right.
ISOC IS a class =22m=22 member of the ITU and has established
a means for ITU-T to make direct reference to Internet Standards
developed by IETF (which operates under the auspices of ISOC).
The procedure was undertaken to facilitate exchange of
information and working group participation between ITU-T
working parties and various IETF working groups. ISOC and
IETF lose none of their autonomy in this arrangement.
Vint Cerf
At 10:07 AM 6/9/97 -0500, Vito Peter Jokubaitis wrote:
>Herman's right=21
>
>ISOC is NOT a member of the ITU. Membership in the ITU is restricted to=
governments. ISOC joined the Sectors (Telecommunications,
Radiocommunications, Development) of the ITU as an international
organization in 1995.
>
Received: from ietf.org by ietf.org id aa06882; 13 Jun 97 9:31 EDT
Received: from ietf.ietf.org by ietf.org id aa06223; 13 Jun 97 9:10 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: ietf-registrar at ietf.org
Subject: IETF MUNICH: REGISTRATION PROBLEM
Date: Fri, 13 Jun 1997 09:10:00 -0400
X-Orig-Sender: mbeaulie at ietf.org
Message-ID: <9706130910.aa06223 at ietf.org>
We have found a bug in our registration program. We are
temporarily suspending registration until this problem
can be fixed. As soon as everything is working correctly,
we will send you a message.
Thank you for your understanding and cooperation.
Julie Kirchhoff
IETF Registrar
Received: from ietf.org by ietf.org id aa06879; 13 Jun 97 9:31 EDT
Received: from ietf.ietf.org by ietf.org id aa06538; 13 Jun 97 9:21 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-perkins-clartc-00.txt
Date: Fri, 13 Jun 1997 09:21:28 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706130921.aa06538 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Clarification for Textual Conventions in SMIv2
Author(s) : D. Perkins
Filename : draft-perkins-clartc-00.txt
Pages : 4
Date : 06/12/1997
This memo is informational. It specifies a clarification of version 2 of
the SNMP SMI, a standard for the Internet community, which is defined by
RFCs 1902[1], 1903[2], and 1904[3]. The clarification is to fix a perceived
inconsistency in the definition of the TEXTUAL-CONVENTION construct. This
problem is resolved by replacement text for section 3.5 of RFC 1903.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-perkins-clartc-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-perkins-clartc-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-perkins-clartc-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970612174744.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-perkins-clartc-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-perkins-clartc-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970612174744.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06883; 13 Jun 97 9:31 EDT
Received: from ietf.ietf.org by ietf.org id aa06559; 13 Jun 97 9:21 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-perkins-bigint-00.txt
Date: Fri, 13 Jun 1997 09:21:31 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706130921.aa06559 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Support for Large Integers in SNMP
Author(s) : D. Perkins
Filename : draft-perkins-bigint-00.txt
Pages : 5
Date : 06/12/1997
This memo is informational. It specifies an approach to add 64-bit signed
and unsigned integer types to versions 1 and 2 of the SNMP
SMI[1][2][3][4][5][6], and versions 1 and 2 of the SNMP protocol[7][8][9]
without changes. Thus, this addition requires no modifications to existing
SNMP MIB compilers, and no changes to existing SNMP protocol engines used
in SNMP agents and SNMP management applications.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-perkins-bigint-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-perkins-bigint-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-perkins-bigint-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970612175139.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-perkins-bigint-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-perkins-bigint-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970612175139.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06889; 13 Jun 97 9:31 EDT
Received: from ietf.ietf.org by ietf.org id aa06500; 13 Jun 97 9:21 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-jeya-vlan-8021q-mib-01.txt
Date: Fri, 13 Jun 1997 09:21:19 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706130921.aa06500 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Definitions of Managed Objects for
IEEE 802.1q Virtual LAN Bridges
Author(s) : I. Jeyasubramanian
Filename : draft-jeya-vlan-8021q-mib-01.txt
Pages : 14
Date : 06/12/1997
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular it describes objects used for managing bridges based on the IEEE
802.1q draft standard between Local Area Network (LAN) segments.
This memo uses SNMPv2 as the basis for defining VLAN MIB, and refers to
other MIBs whose published definitions use SNMPv2 convention
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-jeya-vlan-8021q-mib-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-jeya-vlan-8021q-mib-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-jeya-vlan-8021q-mib-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970612144702.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-jeya-vlan-8021q-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-jeya-vlan-8021q-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970612144702.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07073; 13 Jun 97 9:33 EDT
Received: from ietf.ietf.org by ietf.org id aa06586; 13 Jun 97 9:21 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-perkins-bits-00.txt
Date: Fri, 13 Jun 1997 09:21:33 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706130921.aa06586 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The BITS Pseudotype
Author(s) : D. Perkins
Filename : draft-perkins-bits-00.txt
Pages : 11
Date : 06/12/1997
This memo is informational. It specifies replacement text for version 2 of
the SNMP SMI, which is defined by RFCs 1902[1], 1903[2], and 1904[3], to
fix the incorrect usage of ASN.1 to specify a BITS pseudotype. The BITS
pseudotype must have the look and functions of an ASN.1 type in the
following constructs allowed in SMIv2 format MIB modules: OBJECT-TYPE,
SEQUENCE, MODULE-COMPLIANCE, AGENT-CAPABILITIES, TEXTUAL-CONVENTION, and
type assignments. The ASN.1 macros defined in RFCs 1902, 1903, and 1904 do
not support the requirements.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-perkins-bits-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-perkins-bits-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-perkins-bits-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970612175511.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-perkins-bits-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-perkins-bits-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970612175511.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07324; 13 Jun 97 9:42 EDT
Received: from ietf.ietf.org by ietf.org id aa07204; 13 Jun 97 9:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-srisuresh-01.txt
Date: Fri, 13 Jun 1997 09:38:52 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706130938.aa07204 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The IP Network Address Translator (NAT)
Author(s) : P. Srisuresh, K. Egevang
Filename : draft-rfced-info-srisuresh-01.txt
Pages : 16
Date : 06/12/1997
Basic Network Address Translation or Basic NAT is a feature by which IP
addresses are mapped from one group to another, transparent to users.
Network Address Port Translation, or NAPT is an extension to Basic NAT, in
that many network addresses and their TCP/UDP ports are translated to a
single network address and its TCP/UDP ports.
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-srisuresh-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-srisuresh-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-srisuresh-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970612112307.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-srisuresh-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-srisuresh-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970612112307.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07322; 13 Jun 97 9:42 EDT
Received: from ietf.ietf.org by ietf.org id aa07222; 13 Jun 97 9:39 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-perkins-02.txt
Date: Fri, 13 Jun 1997 09:38:58 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706130939.aa07222 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Clarification of the STATUS Clause in SNMP MIB Modules
Author(s) : D. Perkins
Filename : draft-rfced-info-perkins-02.txt
Pages : 13
Date : 06/12/1997
This memo is informational. It specifies a clarification of the meaning
and use of the STATUS clause in Simple Network Management Protocol (SNMP)
Management Information Base (MIB) modules, which are defined by the
Structure of Management Information (SMI). There are two versions of the
SMI. The first, called SMIv1, is defined by RFCs 1155[1], 1212[2], and
1215[3]. The second, called SMIv2, is defined by RFCs 1902[4], 1903[5],
and 1904[6]. Many of the MIB module constructs defined by the SMIs such as
OBJECT-IDENTITY, OBJECT-TYPE, and NOTIFICATION-TYPE contain the STATUS
clause. However, the SMIs do not provide a complete definition of the
STATUS clause, nor do they provide guidance to MIB designers and users on
the interpretation and action required dependent upon the value or change
of value for a STATUS clause. Users include agent and application
developers, and operators of SNMP-managed networks.
This memo specifies a clarification for both version 1 and version 2
of the SNMP SMI, which is a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-rfced-info-perkins-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-perkins-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-perkins-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970612171232.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-perkins-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-perkins-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970612171232.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11041; 13 Jun 97 12:15 EDT
Received: from ietf.ietf.org by ietf.org id aa10910; 13 Jun 97 12:09 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: ietf-registrar at ietf.org
Subject: IETF MUNICH: REGISTRATION RESUMES
Date: Fri, 13 Jun 1997 12:09:52 -0400
X-Orig-Sender: mbeaulie at ietf.org
Message-ID: <9706131209.aa10910 at ietf.org>
We have corrected the registration glitch, you can once
again register on-line.
We apologize for any inconvenience.
Julie Kirchhoff
IETF Registrar
Received: from ietf.org by ietf.org id aa06598; 15 Jun 97 12:17 EDT
Received: from cs.columbia.edu by ietf.org id aa06339; 15 Jun 97 11:53 EDT
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA05393 for <ietf at ietf.org>; Sun, 15 Jun 1997 11:49:53 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id LAA03062 for <ietf at ietf.org>; Sun, 15 Jun 1997 11:49:52 -0400 (EDT)
X-Orig-Sender: hgs at cs.columbia.edu
Message-ID: <33A40F20.4F7A at cs.columbia.edu>
Date: Sun, 15 Jun 1997 11:49:52 -0400
Sender:ietf-request at ietf.org
From: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: ietf at ietf.org
Subject: Internet capacity Japan - US exceeds phone capacity
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
At a recent Information Infrastructure workshop, Kenichi Kawaguchi
pointed out that the transmission capacity between Japan and the US for
Internet services (650 Mb/s) now significantly exceeds that for
telephony (400 Mb/s). See
http://www.cs.columbia.edu/~hgs/internet/telecom.html
I'd be interested in similar statistics from other places.
--
Henning Schulzrinne email: schulzrinne at cs.columbia.edu
Dept. of Computer Science phone: +1 212 939-7042
Columbia University fax: +1 212 666-0140
New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs
Received: from ietf.org by ietf.org id aa08132; 15 Jun 97 14:30 EDT
Received: from zephyr.isi.edu by ietf.org id aa07947; 15 Jun 97 14:15 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-26)
id <AA02663>; Sun, 15 Jun 1997 11:11:50 -0700
Sender:ietf-request at ietf.org
From: Bill Manning <bmanning at isi.edu>
Message-Id: <199706151811.AA02663 at zephyr.isi.edu>
Subject: Re: Internet capacity Japan - US exceeds phone capacity
To: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
Date: Sun, 15 Jun 1997 11:11:50 -0700 (PDT)
Cc: ietf at ietf.org
In-Reply-To: <33A40F20.4F7A at cs.columbia.edu> from "Henning Schulzrinne" at Jun 15, 97 11:49:52 am
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 257
Source-Info: From (or Sender) name not authenticated.
I beleive that this is true for Australia as of early this year (Geoff
Huston postited as much in Memphis) and both PacBell and AADS are making
similar claims. I've heard rumors that the curve is near crossover
within MCI and Sprint as well.
--
--bill
Received: from cnri by ietf.org id aa10356; 15 Jun 97 17:58 EDT
Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA22076; Sun, 15 Jun 1997 17:57:21 -0400 (EDT)
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <UAA26644 at pad-thai.cam.ov.com>; Sun, 15 Jun 1997 20:25:29 GMT
To: cat-ietf at mit.edu
Subject: Some more ftpsec comments
X-Emacs: 19.34
Mime-Version: 1.0 (generated by SEMI MIME-Edit 0.77)
Content-Type: text/plain; charset=US-ASCII
From: Johan Danielsson <joda at pdc.kth.se>
Date: 15 Jun 1997 22:25:03 +0200
Message-Id: <xofsoyjzk9s.fsf at blubb.pdc.kth.se>
Lines: 40
X-Mailer: Gnus v5.4.52/Emacs 19.34
Precedence: bulk
I don't remember if these topics has been brought up before.
Page 8:
CLEAR COMMAND CHANNEL (CCC)
This command does not take an argument.
It is desirable in some environments to use a security mechanism
to authenticate and/or authorize the client and server, but not to
perform any integrity checking on the subsequent commands. This
might be used in an environment where IP security is in place,
insuring that the hosts are authenticated and that TCP streams
cannot be tampered, but where user authentication is desired.
A comment about the application with NAT might be useful here as well
(unless someone can come up with a good solution to this problem).
Page 21:
The server must base 64 decode the argument to the ADAT command and
pass the result to krb_rd_req(3). The server must add one to the
checksum from the authenticator, convert the result to network byte
order (most significant byte first), and sign it using
krb_mk_safe(3), and base 64 encode the result. Upon success, the
server must reply to the client with a 235 code and include
"ADAT=base64string" in the text of the reply. Upon failure, the
server should reply 535.
It should be clarified that the returned value should be the lower 32
bits of the result of the addition (I leave to someone else to put
that in words :-).
BTW, what is currently happening with this draft? The Memphis minutes
mentioned a new draft, but then everything went silent.
/Johan
Received: from ietf.org by ietf.org id aa04838; 16 Jun 97 7:48 EDT
Received: from ietf.ietf.org by ietf.org id aa04314; 16 Jun 97 7:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipngwg-multicast-assgn-03.txt
Date: Mon, 16 Jun 1997 07:17:54 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706160718.aa04314 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 IPNG Working Group of the
IETF.
Title : IPv6 Multicast Address Assignments
Author(s) : R. Hinden, S. Deering
Filename : draft-ietf-ipngwg-multicast-assgn-03.txt
Pages : 8
Date : 06/13/1997
This document defines the initial assignment of IPv6 multicast addresses.
It is based on the "IP Version 6 Addressing Architecture" [ADDARCH] and
current IPv4 multicast address assignment found in
<ftp://venera.isi.edu/in-notes/iana/assignments/multicast-addresses>. It
adapts the IPv4 assignments that are relevant to IPv6 assignments. IPv4
assignments that were not relevant were not converted into IPv6
assignments. Comments are solicited on this conversion.
All other IPv6 multicast addresses are reserved.
Sections 2 and 3 specify reserved and preassigned IPv6 multicast addresses.
[ADDRARCH] defines rules for assigning new IPv6 multicast addresses.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
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-ipngwg-multicast-assgn-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-multicast-assgn-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipngwg-multicast-assgn-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970616070239.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-multicast-assgn-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-multicast-assgn-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970616070239.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05961; 16 Jun 97 8:47 EDT
Received: from ietf.ietf.org by ietf.org id aa05793; 16 Jun 97 8:40 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-richardson-ipsec-traversal-00.txt
Date: Mon, 16 Jun 1997 08:40:32 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706160840.aa05793 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Firewall Traversal authorization system
Author(s) : M. Richardson
Filename : draft-richardson-ipsec-traversal-00.txt
Pages : 10
Date : 06/13/1997
This document describes a public key certificate mechanism to authorize
traversal of multiple security gateways (firewalls). This work is
independant of transport layer in concept, and could apply to IPsec, TLS,
or SecSH. It is applied here to IPsec. The SPKI certificate format is used
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-richardson-ipsec-traversal-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-richardson-ipsec-traversal-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-richardson-ipsec-traversal-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970616070306.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-richardson-ipsec-traversal-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-richardson-ipsec-traversal-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970616070306.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05962; 16 Jun 97 8:47 EDT
Received: from ietf.ietf.org by ietf.org id aa05772; 16 Jun 97 8:40 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipngwg-addr-arch-v2-01.txt
Date: Mon, 16 Jun 1997 08:40:19 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706160840.aa05772 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IP Version 6 Addressing Architecture
Author(s) : R. Hinden, S. Deering
Filename : draft-ietf-ipngwg-addr-arch-v2-01.txt
Pages : 25
Date : 06/13/1997
This specification defines the addressing architecture of the IP Version 6
protocol [IPV6]. The document includes the IPv6 addressing model, text
representations of IPv6 addresses, definition of IPv6 unicast addresses,
anycast addresses, and multicast addresses, and an IPv6 nodes required
addresses.
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-ipngwg-addr-arch-v2-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-addr-arch-v2-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-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.
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: <19970616070259.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v2-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-addr-arch-v2-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970616070259.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06069; 16 Jun 97 8:49 EDT
Received: from cbgw2.lucent.com by ietf.org id aa05921; 16 Jun 97 8:44 EDT
To: Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Bill Manning <bmanning at isi.edu>
Received: from mvjok.mv.lucent.com by cbig2.firewall.lucent.com (SMI-8.6/EMS-L sol2)
id IAA05089; Mon, 16 Jun 1997 08:39:30 -0400
Received: by mvjok.mv.lucent.com (5.x/EMS-L sol2)
id AA22992; Mon, 16 Jun 1997 08:40:36 -0400
Original-To: Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Bill Manning <bmanning at isi.edu>
Received: from ftfls.mv.lucent.com by mvjok.mv.lucent.com (5.x/EMS-L sol2)
id AA22986; Mon, 16 Jun 1997 08:40:34 -0400
Received: from ftfls by ftfls.mv.lucent.com (SMI-8.6/EMS-L sol2)
id IAA01395; Mon, 16 Jun 1997 08:36:55 -0400
X-Orig-Sender: ewgray at mvjok.mv.lucent.com
Message-Id: <33A53367.2CBD at lucent.com>
Date: Mon, 16 Jun 1997 08:36:55 -0400
Sender:ietf-request at ietf.org
From: Eric W Gray <ewgray at lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 3.01 (X11; U; SunOS 5.5 sun4u)
Mime-Version: 1.0
Original-To: Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Bill Manning <bmanning at isi.edu>
Cc: ietf at ietf.org
Subject: Re: Internet capacity Japan - US exceeds phone capacity
References: <199706151811.AA02663 at zephyr.isi.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Re: Data/Telephony X-Over Japan/Australia
Please, do not try to tell me that you find this surprising for
some unguessable reason. Compare what it costs to check out the
Web sites in Autralia and Japan (0 dollars, 0 cents) to what it
costs to call either of these locations. And that without taking
into account the obvious effect of the use of Internet Phone for
these same calls.
--
Eric Gray Email: ewgray at lucent.com
Voice: (508)960-6162 Fax: (508)960-6095
In Person:MV 21-2E33 1600 Osgood St., N. Andover, MA 01845
Received: from ietf.org by ietf.org id aa10580; 16 Jun 97 12:34 EDT
Received: from aland.bbn.com by ietf.org id aa10376; 16 Jun 97 12:21 EDT
Received: (from craig at localhost) by aland.bbn.com (8.7.1/8.7.1) id JAA05440; Mon, 16 Jun 1997 09:16:23 -0700 (PDT)
Message-Id: <199706161616.JAA05440 at aland.bbn.com>
To: Eric W Gray <ewgray at lucent.com>
cc: Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Bill Manning <bmanning at isi.edu>, ietf at ietf.org
Subject: Re: Internet capacity Japan - US exceeds phone capacity
In-reply-to: Your message of Mon, 16 Jun 97 08:36:55 -0400.
<33A53367.2CBD at lucent.com>
Date: Mon, 16 Jun 97 09:16:22 -0700
Sender:ietf-request at ietf.org
From: Craig Partridge <craig at aland.bbn.com>
Source-Info: From (or Sender) name not authenticated.
Re: Data/Telephony X-Over Japan/Australia
Please, do not try to tell me that you find this surprising for
some unguessable reason. Compare what it costs to check out the
Web sites in Autralia and Japan (0 dollars, 0 cents) to what it
costs to call either of these locations. And that without taking
into account the obvious effect of the use of Internet Phone for
these same calls.
Pardon me -- I don't understand this comment.
In both cases someone is paying for the bandwidth (ISP or telephony provider)
and recouping their costs through customer charges.
So what Henning's numbers say is more folks are paying for data than voice/fax
across the Pacific.
People like to make a point that ISPs are losing money, but if you look
deeply at the ISP business models, they're generally not losing money
on long-time customers (or if so, only a tiny bit). Their losses are
primarily due to growth costs (hiring and training new staff, putting
POPs into new territories [which will be underutilized for some number
of months], etc).
Craig
Received: from ietf.org by ietf.org id aa11852; 16 Jun 97 13:55 EDT
Received: from bells.cs.ucl.ac.uk by ietf.org id aa11741; 16 Jun 97 13:49 EDT
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.02930-0 at bells.cs.ucl.ac.uk>; Mon, 16 Jun 1997 18:34:03 +0100
To: Craig Partridge <craig at aland.bbn.com>
cc: Eric W Gray <ewgray at lucent.com>,
Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Bill Manning <bmanning at isi.edu>, ietf at ietf.org, J.Crowcroft at cs.ucl.ac.uk
Subject: Re: Internet capacity Japan - US exceeds phone capacity
In-reply-to: Your message of "Mon, 16 Jun 1997 09:16:22 PDT." <199706161616.JAA05440 at aland.bbn.com>
Date: Mon, 16 Jun 1997 18:34:02 +0100
Message-ID: <429.866482442 at cs.ucl.ac.uk>
Sender:ietf-request at ietf.org
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Source-Info: From (or Sender) name not authenticated.
>
> Re: Data/Telephony X-Over Japan/Australia
>
> Please, do not try to tell me that you find this surprising for
> some unguessable reason. Compare what it costs to check out the
> Web sites in Autralia and Japan (0 dollars, 0 cents) to what it
> costs to call either of these locations. And that without taking
> into account the obvious effect of the use of Internet Phone for
> these same calls.
>Pardon me -- I don't understand this comment.
hey - its worse than that
australians DO charge for web/internet access:-)
>
>In both cases someone is paying for the bandwidth (ISP or telephony provider)
>and recouping their costs through customer charges.
>
>So what Henning's numbers say is more folks are paying for data than voice/fax
>across the Pacific.
>
>People like to make a point that ISPs are losing money, but if you look
>deeply at the ISP business models, they're generally not losing money
>on long-time customers (or if so, only a tiny bit). Their losses are
>primarily due to growth costs (hiring and training new staff, putting
>POPs into new territories [which will be underutilized for some number
>of months], etc).
>
>Craig
jon
Received: from ietf.org by ietf.org id aa14958; 16 Jun 97 17:04 EDT
Received: from mailhost.ipsilon.com by ietf.org id aa14089; 16 Jun 97 16:04 EDT
Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id MAA05102; Mon, 16 Jun 1997 12:59:26 -0700
Message-Id: <3.0.2.32.19970616125924.0069aafc at mailhost.ipsilon.com>
X-Sender: hinden at mailhost.ipsilon.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Mon, 16 Jun 1997 12:59:24 -0700
To: Craig Partridge <craig at aland.bbn.com>
Sender:ietf-request at ietf.org
From: Bob Hinden <hinden at ipsilon.com>
Subject: Re: Internet capacity Japan - US exceeds phone capacity
Cc: ietf at ietf.org
In-Reply-To: <199706161616.JAA05440 at aland.bbn.com>
References: <Your message of Mon, 16 Jun 97 08:36:55 -0400. <33A53367.2CBD at lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
Craig,
>In both cases someone is paying for the bandwidth (ISP or telephony provider)
>and recouping their costs through customer charges.
>
>So what Henning's numbers say is more folks are paying for data than
voice/fax
>across the Pacific.
I think it is more than just the number of users. It is also how the
bandwidth is purchased. For internet traffic the bandwidth is being
purchased in bulk (i.e., "wholesale"), while for voice traffic the calls
are paid for individually (i.e., "retail").
Bob
Received: from ietf.org by ietf.org id aa14966; 16 Jun 97 17:04 EDT
Received: from ietf.ietf.org by ietf.org id aa14265; 16 Jun 97 16:13 EDT
To: IETF-Announce: ;
cc: rps at isi.edu
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: Routing Policy Specification Language (RPSL) to
Proposed Standard
Reply-to: iesg at ietf.org
Date: Mon, 16 Jun 1997 16:13:03 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706161613.aa14265 at ietf.org>
The IESG has received a request from the Routing Policy System Working
Group to consider "Routing Policy Specification Language (RPSL)"
<draft-ietf-rps-rpsl-02.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 June 30, 1997
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa14971; 16 Jun 97 17:04 EDT
Received: from aland.bbn.com by ietf.org id aa14296; 16 Jun 97 16:17 EDT
Received: (from craig at localhost) by aland.bbn.com (8.7.1/8.7.1) id NAA06092; Mon, 16 Jun 1997 13:11:51 -0700 (PDT)
Message-Id: <199706162011.NAA06092 at aland.bbn.com>
To: Bob Hinden <hinden at ipsilon.com>
cc: Craig Partridge <craig at aland.bbn.com>, ietf at ietf.org
Subject: Re: Internet capacity Japan - US exceeds phone capacity
In-reply-to: Your message of Mon, 16 Jun 97 12:59:24 -0700.
<3.0.2.32.19970616125924.0069aafc at mailhost.ipsilon.com>
Date: Mon, 16 Jun 97 13:11:48 -0700
Sender:ietf-request at ietf.org
From: Craig Partridge <craig at aland.bbn.com>
Source-Info: From (or Sender) name not authenticated.
Craig,
>In both cases someone is paying for the bandwidth (ISP or telephony provid
er)
>and recouping their costs through customer charges.
>
>So what Henning's numbers say is more folks are paying for data than
voice/fax
>across the Pacific.
I think it is more than just the number of users. It is also how the
bandwidth is purchased. For internet traffic the bandwidth is being
purchased in bulk (i.e., "wholesale"), while for voice traffic the calls
are paid for individually (i.e., "retail").
Bob:
You're right, I meant to say more bandwidth is being purchased for
data than voice/fax.
Whether people are actually getting a discount from bandwidth in bulk
is, I think, less clear. I suspect discounts depend on where you sit
in the consumer foodchain. For example, as I understand things, ISPs are
buying capacity from telcos that own the fiber (and unless there's some
regulatory issue, I assume a telco would charge an ISPs somewhat more than
than what they would charge their internal telephony group.
Craig
Received: from cnri by ietf.org id aa15096; 16 Jun 97 17:06 EDT
Received: from external.BSDI.COM (external.BSDI.COM [205.230.225.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA24849 for <IETF-archive at cnri.reston.va.us>; Mon, 16 Jun 1997 17:05:14 -0400 (EDT)
Received: (from daemon at localhost)
by external.BSDI.COM (8.8.5/8.8.5) id OAA15352
for telnet-ietf-list at bsdi.com; Mon, 16 Jun 1997 14:45:21 -0600 (MDT)
Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189])
by external.BSDI.COM (8.8.5/8.8.5) with ESMTP id OAA15347
for <telnet-ietf at bsdi.com>; Mon, 16 Jun 1997 14:45:19 -0600 (MDT)
Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK)
id QAA15391; Mon, 16 Jun 1997 16:45:11 -0400 (EDT)
Message-Id: <199706162045.QAA15391 at spot.cs.utk.edu>
To: telnet-ietf at bsdi.com
Subject: Last Call: Telnet Comport Control Option to Proposed Standard
Date: Mon, 16 Jun 1997 16:45:11 -0400
From: Keith Moore <moore at cs.utk.edu>
Hi. I'd like to know what telnet implementors think of this,
if there are any problems with it, etc.
The last call has expired, but due to INET'97 and US Independence Day,
IESG won't ballot this for several more weeks.
There's also a competing proposal; I'll send along the internet-draft
name once I dig it up.
thanks!
Keith Moore
Applications AD
IESG
------- Forwarded Message
To: IETF-Announce at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: Telnet Comport Control Option to Proposed Standard
Date: Tue, 29 Apr 1997 18:34:07 EDT
The IESG has received a request to consider "Telnet Comport Control
Option <draft-clark-telnet-control-02.txt> as a Proposed Standard.
This has been reviewed in the IETF but is not the product of an IETF
Working Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by June 30, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
------- End of Forwarded Message
Received: from ietf.org by ietf.org id aa15226; 16 Jun 97 17:10 EDT
Received: from ietf.ietf.org by ietf.org id aa15088; 16 Jun 97 17:05 EDT
To: IETF-Announce: ;
cc: oncrpc-wg at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: RPCSEC_GSS Protocol Specification to Proposed Standard
Reply-to: iesg at ietf.org
Date: Mon, 16 Jun 1997 17:05:56 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706161705.aa15088 at ietf.org>
The IESG has received a request from the ONC Remote Procedure Call
Working Group to consider "RPCSEC_GSS Protocol Specification"
<draft-ietf-oncrpc-rpcsec_gss-05.txt> for the status of Proposed
Standard.
The IESG will also consider publication of Authentication Mechanisms
for ONC RPC <draft-ietf-oncrpc-auth-03.txt> as an Informational RFC.
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 June 30, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa15369; 16 Jun 97 17:14 EDT
Received: from ietf.ietf.org by ietf.org id aa15284; 16 Jun 97 17:12 EDT
To: IETF-Announce: ;
cc: ietf-mixer at innosoft.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: Using the Internet DNS to Distribute MIXER Conformant
Global Address Mapping (MCGAM) to Proposed Standard
Reply-to: iesg at ietf.org
Date: Mon, 16 Jun 1997 17:12:05 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706161712.aa15284 at ietf.org>
The IESG has received a request from the MIME - X.400 Gateway Working
Group to consider "Using the Internet DNS to Distribute MIXER
Conformant Global Address Mapping (MCGAM)"
<draft-ietf-mixer-rfc1664bis-00.txt> for the status of Proposed
Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by June 30.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa15501; 16 Jun 97 17:18 EDT
Received: from ietf.ietf.org by ietf.org id aa15437; 16 Jun 97 17:15 EDT
To: IETF-Announce: ;
cc: ietf-mixer at innosoft.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: Use of an X.500/LDAP directory to support MIXER address
mapping to Proposed Standard
Reply-to: iesg at ietf.org
Date: Mon, 16 Jun 1997 17:15:58 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706161715.aa15437 at ietf.org>
The IESG has received a request from the MIME - X.400 Gateway Working
Group to consider "Use of an X.500/LDAP directory to support MIXER address
mapping" <draft-ietf-mixer-directory-01.txt> for the status of Proposed
Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by June 30.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa15768; 16 Jun 97 17:33 EDT
Received: from cs.columbia.edu by ietf.org id aa15724; 16 Jun 97 17:30 EDT
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id RAA16025; Mon, 16 Jun 1997 17:26:54 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id RAA08771; Mon, 16 Jun 1997 17:26:53 -0400 (EDT)
X-Orig-Sender: hgs at cs.columbia.edu
Message-ID: <33A5AF9D.2471 at cs.columbia.edu>
Date: Mon, 16 Jun 1997 17:26:53 -0400
Sender:ietf-request at ietf.org
From: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Craig Partridge <craig at aland.bbn.com>
CC: ietf at ietf.org
Subject: Re: Internet capacity Japan - US exceeds phone capacity
References: <199706162011.NAA06092 at aland.bbn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Craig Partridge wrote:
>
> Whether people are actually getting a discount from bandwidth in bulk
> is, I think, less clear. I suspect discounts depend on where you sit
> in the consumer foodchain. For example, as I understand things, ISPs are
> buying capacity from telcos that own the fiber (and unless there's some
> regulatory issue, I assume a telco would charge an ISPs somewhat more than
> than what they would charge their internal telephony group.
An article by Jonathan Turner (at
http://www.arl.wustl.edu/~jst/TransPrice.html) complains that the telcos
are actually charging basically as multiples of 64 kb/s rather than
giving volume discounts. However, this would "only" affect internal
accounting at companies that run their own facilities (like KDD and MCI,
I assume) instead of leasing them from facilities-based carriers.
>
> Craig
Henning
Received: from ietf.org by ietf.org id aa15985; 16 Jun 97 17:41 EDT
Received: from aland.bbn.com by ietf.org id aa15912; 16 Jun 97 17:39 EDT
Received: (from craig at localhost) by aland.bbn.com (8.7.1/8.7.1) id OAA06272; Mon, 16 Jun 1997 14:34:02 -0700 (PDT)
Message-Id: <199706162134.OAA06272 at aland.bbn.com>
To: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
cc: ietf at ietf.org
Subject: Re: Internet capacity Japan - US exceeds phone capacity
In-reply-to: Your message of Mon, 16 Jun 97 17:26:53 -0400.
<33A5AF9D.2471 at cs.columbia.edu>
Date: Mon, 16 Jun 97 14:34:01 -0700
Sender:ietf-request at ietf.org
From: Craig Partridge <craig at aland.bbn.com>
Source-Info: From (or Sender) name not authenticated.
Craig Partridge wrote:
>
> Whether people are actually getting a discount from bandwidth in bulk
> is, I think, less clear. I suspect discounts depend on where you sit
> in the consumer foodchain. For example, as I understand things, ISPs are
> buying capacity from telcos that own the fiber (and unless there's some
> regulatory issue, I assume a telco would charge an ISPs somewhat more tha
n
> than what they would charge their internal telephony group.
An article by Jonathan Turner (at
http://www.arl.wustl.edu/~jst/TransPrice.html) complains that the telcos
are actually charging basically as multiples of 64 kb/s rather than
giving volume discounts. However, this would "only" affect internal
accounting at companies that run their own facilities (like KDD and MCI,
I assume) instead of leasing them from facilities-based carriers.
I assume that's true internationally.
Domestically, as I understand things, the rules are somewhat different.
A senior person at one carrier told me that their leases for rights-of-way
are actually measured in 64 Kb/s channels carried. (There are some
interesting ramifications here, which I don't claim to fully understand.
But one is that since rights-of-way are a large part of the cost, improvements
in technology may have only a limited impact on costs).
Craig
Received: from ietf.org by ietf.org id aa17018; 16 Jun 97 19:02 EDT
Received: from zephyr.isi.edu by ietf.org id aa16901; 16 Jun 97 18:59 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
id <AA18599>; Mon, 16 Jun 1997 15:55:08 -0700
Message-Id: <199706162255.AA18599 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2117 on PIM-SM
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 16 Jun 97 15:55:07 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 2117:
Title: Protocol Independent Multicast-Sparse Mode
(PIM-SM): Protocol Specification
Author: D. Estrin, D. Farinacci, A. Helmy, D. Thaler,
S. Deering, M. Handley, V. Jacobson, C. Liu,
P. Sharma, L. Wei
Date: June 1997
Mailbox: estrin at usc.edu, dino at cisco.com,
ahelmy at catarina.usc.edu, thalerd at eecs.umich.edu,
deering at parc.xerox.com, m.handley at cs.ucl.ac.uk,
van at ee.lbl.gov, charley at catarina.usc.edu,
puneet at catarina.usc.edu, lwei at cisco.com
Pages: 66
Characters: 151886
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2117.txt
This document describes a protocol for efficiently routing to
multicast groups that may span wide-area (and inter-domain) internets.
This document is the product of the Inter-Domain Multicast Routing
Working Group of the IETF.
This memo defines an Experimental Protocol for the Internet community.
This memo does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970616155045.RFC at ISI.EDU>
SEND /rfc/rfc2117.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2117.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970616155045.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17011; 16 Jun 97 19:02 EDT
Received: from relay5.UU.NET by ietf.org id aa16915; 16 Jun 97 18:59 EDT
Received: from rodan.UU.NET by relay5.UU.NET with ESMTP
(peer crosschecked as: rodan.UU.NET [153.39.130.10])
id QQcufz13816; Mon, 16 Jun 1997 18:55:31 -0400 (EDT)
Received: from sayshell.UU.NET by rodan.UU.NET with SMTP
(peer crosschecked as: sayshell.UU.NET [153.39.251.30])
id QQcufz20902; Mon, 16 Jun 1997 18:55:07 -0400 (EDT)
Message-Id: <QQcufz20902.199706162255 at rodan.UU.NET>
To: Craig Partridge <craig at aland.bbn.com>
cc: Bob Hinden <hinden at ipsilon.com>, ietf at ietf.org
Sender:ietf-request at ietf.org
From: "Louis A. Mamakos" <louie at uu.net>
Subject: Re: Internet capacity Japan - US exceeds phone capacity
References: <199706162011.NAA06092 at aland.bbn.com>
In-reply-to: Your message of "Mon, 16 Jun 1997 13:11:48 PDT."
<199706162011.NAA06092 at aland.bbn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 16 Jun 1997 18:55:07 -0400
X-Orig-Sender: louie at uu.net
Source-Info: From (or Sender) name not authenticated.
>
> Craig,
>
> >In both cases someone is paying for the bandwidth (ISP or telephony provid
> er)
> >and recouping their costs through customer charges.
> >
> >So what Henning's numbers say is more folks are paying for data than
> voice/fax
> >across the Pacific.
>
> I think it is more than just the number of users. It is also how the
> bandwidth is purchased. For internet traffic the bandwidth is being
> purchased in bulk (i.e., "wholesale"), while for voice traffic the calls
> are paid for individually (i.e., "retail").
>
> Bob:
>
> You're right, I meant to say more bandwidth is being purchased for
> data than voice/fax.
>
> Whether people are actually getting a discount from bandwidth in bulk
> is, I think, less clear. I suspect discounts depend on where you sit
> in the consumer foodchain. For example, as I understand things, ISPs are
> buying capacity from telcos that own the fiber (and unless there's some
> regulatory issue, I assume a telco would charge an ISPs somewhat more than
> than what they would charge their internal telephony group.
Terrestrial trans-oceanic capacity is a horse of a different color. Generally,
the facilities are not owned by a single carrier; a consortium is usually the
"owner" and operator of these systems. Various carriers each buy various
proportions of their half of the cables. In order to own a piece of the cable,
the carrier must be licensed by the relevent agencies in the country that the
end of the cable lands in. Because of this, you've got to go make your deals
a half-circuit at a time.
Further, the available capacity is *very* limited, and it takes a while to make
more. Given that demand is high compared to supply, don't expect any great deals
on transoceanic capacity, which has never been, ah, inexpensive in the past.
Only very recently have most of the cable consortium owner figured out what
this demand for private line Internet use is. They are very much used to selling
DS0's for voice. If you ask for a big chunk of bandwidth, you might just get
it as a bunch of non-coherent (fractional, even) T1 or E1 chunks which you are
left to Inverse-MUX, load balance or perform other unnatural acts on to push
your Internet traffic over.
It's my impression that getting a whole, coherent DS3 under the Pacific these
days is fair amazing thing to pull off, if it's even possible any longer.
Louis Mamakos
Received: from ietf.org by ietf.org id aa17116; 16 Jun 97 19:04 EDT
Received: from zephyr.isi.edu by ietf.org id aa17055; 16 Jun 97 19:02 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
id <AA19048>; Mon, 16 Jun 1997 15:58:41 -0700
Message-Id: <199706162258.AA19048 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2154 on OSPF with Digital Signatures
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 16 Jun 97 15:58:41 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.
Title: OSPF with Digital Signatures
Author: S. Murphy, M. Badger, B. Wellington
Date: June 1997
Mailbox: murphy at tis.com, mrb at tis.com, bwelling at tis.com
Pages: 29
Characters: 72701
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2154.txt
This memo describes the extensions to OSPF required to add digital
signature authentication to Link State data, and to provide a
certification mechanism for router data. Added LSA processing and key
management is detailed. A method for migration from, or co-existence
with, standard OSPF V2 is described.
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970616155543.RFC at ISI.EDU>
SEND /rfc/rfc2154.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2154.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970616155543.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17336; 16 Jun 97 19:18 EDT
Received: from zephyr.isi.edu by ietf.org id aa17265; 16 Jun 97 19:15 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
id <AA20088>; Mon, 16 Jun 1997 16:11:54 -0700
Message-Id: <199706162311.AA20088 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2155 on Definitions of Managed Objects for APPN
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 16 Jun 97 16:11:53 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 2155:
Title: Definitions of Managed Objects for APPN using
SMIv2
Author: B. Clouston, B. Moore
Date: June 1997
Mailbox: clouston at cisco.com, remoore at ralvm6.vnet.ibm.com
Pages: 124
Characters: 213809
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2155.txt
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 monitoring and controlling
network devices with APPN (Advanced Peer-to-Peer Networking)
capabilities. This memo identifies managed objects for the APPN
protocol. This document is the product of the SNA NAU Services MIB
Working Group of the IETF.
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 is now a Proposed Standard Protocol.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970616160049.RFC at ISI.EDU>
SEND /rfc/rfc2155.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2155.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970616160049.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17851; 16 Jun 97 20:08 EDT
Received: from cs.columbia.edu by ietf.org id aa17776; 16 Jun 97 20:06 EDT
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id UAA21001; Mon, 16 Jun 1997 20:01:44 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id UAA09367; Mon, 16 Jun 1997 20:01:43 -0400 (EDT)
X-Orig-Sender: hgs at cs.columbia.edu
Message-ID: <33A5D3E7.327B at cs.columbia.edu>
Date: Mon, 16 Jun 1997 20:01:43 -0400
Sender:ietf-request at ietf.org
From: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: "Louis A. Mamakos" <louie at uu.net>
CC: ietf at ietf.org
Subject: Re: Internet capacity Japan - US exceeds phone capacity
References: <199706162011.NAA06092 at aland.bbn.com> <QQcufz20902.199706162255 at rodan.UU.NET>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
For some prices on cable, see
http://www.cs.columbia.edu/~hgs/internet/telecom.html
The cost of the APCN was quoted to me recently as $1.18 billion or $9755
per 64 kb/s voice circuit or $5.7m for a T3. I was told that the
consortium sells "shares"; non-routine maintenance (if a shark has
discovered a taste for fiber, say) is split as it occurs. Presumably, if
the cable is a total loss, you hope for insurance.
Louis A. Mamakos wrote:
> Further, the available capacity is *very* limited, and it takes a while to make
> more. Given that demand is high compared to supply, don't expect any great deals
> on transoceanic capacity, which has never been, ah, inexpensive in the past.
>
> Only very recently have most of the cable consortium owner figured out what
> this demand for private line Internet use is. They are very much used to selling
> DS0's for voice. If you ask for a big chunk of bandwidth, you might just get
> it as a bunch of non-coherent (fractional, even) T1 or E1 chunks which you are
> left to Inverse-MUX, load balance or perform other unnatural acts on to push
> your Internet traffic over.
>
> It's my impression that getting a whole, coherent DS3 under the Pacific these
> days is fair amazing thing to pull off, if it's even possible any longer.
>
> Louis Mamakos
--
Henning Schulzrinne email: schulzrinne at cs.columbia.edu
Dept. of Computer Science phone: +1 212 939-7042
Columbia University fax: +1 212 666-0140
New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs
Received: from ietf.org by ietf.org id aa21384; 16 Jun 97 22:50 EDT
Received: from mh1.cts.com by ietf.org id aa21285; 16 Jun 97 22:46 EDT
Received: from pnetguru.6SigmaNets.com (netguru.cts.com [204.94.77.43]) by mh1.cts.com (8.8.5/8.8.5) with SMTP id TAA29152; Mon, 16 Jun 1997 19:41:55 -0700 (PDT)
Message-Id: <3.0.1.32.19970616184043.006d4db0 at mail.cts.com>
X-Sender: kwe at mail.cts.com (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 16 Jun 1997 18:40:43 -0700
To: Bill Manning <bmanning at isi.edu>,
Henning Schulzrinne <schulzrinne at cs.columbia.edu>
Sender:ietf-request at ietf.org
From: "Kent W. England" <kwe at 6sigmanets.com>
Subject: Re: Internet capacity exceeds phone capacity
Cc: ietf at ietf.org
In-Reply-To: <199706151811.AA02663 at zephyr.isi.edu>
References: <33A40F20.4F7A at cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
At 11:11 AM 15-06-97 -0700, Bill Manning wrote:
>
>I beleive that this is true for Australia as of early this year (Geoff
>Huston postited as much in Memphis) and both PacBell and AADS are making
>similar claims. I've heard rumors that the curve is near crossover
>within MCI and Sprint as well.
>
>--
>--bill
>
>
Passover comes earlier and earlier. Passover is what I call the event when
Internet traffic volume, however measured, exceeds the volume of telephony
traffic, however measured.
I had been expecting Passover in a couple of years more time, but perhaps
folks are moving the fax and Internet dial access traffic into the Internet
traffic bin, which would greatly accelerate the date of Passover.
The telecomm world will change profoundly when Internet traffic volume is
5-10x of telephony traffic, a couple more years down the road. At that
point, the telephony network engineers will be calling on the Internet
engineers, asking for a few megabits of QoS-pipe from hither to yon to
carry legacy voice traffic. And I'm sure that the Internet engineers will
fundamentally change the business model for renting and burying fiber
capacity.
--Kent
Received: from ietf.org by ietf.org id aa05553; 17 Jun 97 7:46 EDT
Received: from ietf.ietf.org by ietf.org id aa04708; 17 Jun 97 7:27 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-nai-05.txt
Date: Tue, 17 Jun 1997 07:27:26 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706170727.aa04708 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Roaming Operations Working
Group of the IETF.
Title : The Network Access Identifier
Author(s) : B. Aboba
Filename : draft-ietf-roamops-nai-05.txt
Pages : 4
Date : 06/16/1997
In order to enhance the interoperability of roaming and tunneling services,
it is desirable to have a standardized method for identifying users. This
document proposes syntax for the Network Access Identifier (NAI). It is
expected that this will be of interest for support of roaming as well as
tunneling. "Roaming capability" may be loosely defined as the ability to
use any one of multiple Internet service providers (ISPs), while
maintaining a formal, customer-vendor relationship with only one. Examples
of cases where roaming capability might be required include ISP
"confederations" and ISP-provided corporate network access support.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-nai-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-nai-05.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-nai-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970616105305.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-nai-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-nai-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970616105305.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05559; 17 Jun 97 7:46 EDT
Received: from ietf.ietf.org by ietf.org id aa04431; 17 Jun 97 7:20 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipngwg-ipv6router-alert-02.txt
Date: Tue, 17 Jun 1997 07:20:52 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706170720.aa04431 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 IPNG Working Group of the
IETF.
Note: This revision reflects comments received during the last call period.
Title : IPv6 Router Alert Option
Author(s) : D. Katz, R. Atkinson, C. Partridge, A. Jackson
Filename : draft-ietf-ipngwg-ipv6router-alert-02.txt
Pages : 5
Date : 04/21/1997
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-ietf-ipngwg-ipv6router-alert-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6router-alert-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipngwg-ipv6router-alert-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970616094639.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-ipv6router-alert-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-ipv6router-alert-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970616094639.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05560; 17 Jun 97 7:46 EDT
Received: from ietf.ietf.org by ietf.org id aa04602; 17 Jun 97 7:23 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-cohen-http-305-306-responses-00.txt
Date: Tue, 17 Jun 1997 07:23:14 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706170723.aa04602 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : HTTP/1.1 305 and 306 Response Codes
Author(s) : J. Cohen
Filename : draft-cohen-http-305-306-responses-00.txt
Pages : 8
Date : 06/16/1997
This document describes various problems which have arisen in attempts to
deliver negotiated content using HTTP and examines several scenarios by
which improvements in delivery might be accomplished.
This document does not discuss how HTTP might be used to negotiate the use
of other protocols to deliver content.
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-cohen-http-305-306-responses-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-cohen-http-305-306-responses-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-cohen-http-305-306-responses-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970616103435.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-cohen-http-305-306-responses-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-cohen-http-305-306-responses-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970616103435.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05563; 17 Jun 97 7:46 EDT
Received: from ietf.ietf.org by ietf.org id aa04747; 17 Jun 97 7:27 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-imprev-04.txt
Date: Tue, 17 Jun 1997 07:27:34 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706170727.aa04747 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Roaming Operations Working
Group of the IETF.
Title : Review of Roaming Implementations
Author(s) : B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang
Filename : draft-ietf-roamops-imprev-04.txt
Pages : 32
Date : 06/16/1997
This document reviews the design and functionality of existing roaming
implementations. "Roaming capability" may be loosely defined as the
ability to use any one of multiple Internet service providers (ISPs), while
maintaining a formal, customer-vendor relationship with only one. Examples
of cases where roaming capability might be required include ISP
"confederations" and ISP-provided corporate network access support.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-imprev-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-imprev-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-imprev-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970616105647.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-imprev-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-imprev-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970616105647.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05565; 17 Jun 97 7:46 EDT
Received: from ietf.ietf.org by ietf.org id aa04780; 17 Jun 97 7:27 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-16.txt, .ps
Date: Tue, 17 Jun 1997 07:27:45 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706170727.aa04780 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.
Note: This revision reflects comments received during the last call period.
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-16.txt, .ps
Pages : 111
Date : 06/16/1997
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-16.txt".
Or
"get draft-ietf-rsvp-spec-16.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-spec-16.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rsvp-spec-16.txt".
Or
"FILE /internet-drafts/draft-ietf-rsvp-spec-16.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.
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: <19970616110650.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rsvp-spec-16.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-spec-16.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970616110650.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05555; 17 Jun 97 7:46 EDT
Received: from ietf.ietf.org by ietf.org id aa04464; 17 Jun 97 7:21 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-pppext-l2tp-sec-00.txt
Date: Tue, 17 Jun 1997 07:20:37 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706170721.aa04464 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : Layer Two Tunneling Protocol "L2TP" - Security
Extensions for Non-IP networks
Author(s) : Pat Calhoun, W. Mark Townsley
Filename : draft-ietf-pppext-l2tp-sec-00.txt
Pages : 8
Date : 06/16/1997
The L2TP Document defines the base protocol which describes the method
of tunneling PPP data. The spec states that the security mechanism used
over an IP network is to use the IETF's IPSEC protocols. L2TP
was designed in such a way as to be able to run over any underlying layer
(i.e. Frame Relay, ATM, etc.). This document specifies extensions to the
L2TP protocol in order to provide authentication and integrity of
individual packets in a tunneled session over a non-IP network. It does not
intend to provide a mechanism for encryption of packets.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pppext-l2tp-sec-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-sec-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-l2tp-sec-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970616093318.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-l2tp-sec-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-l2tp-sec-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970616093318.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05556; 17 Jun 97 7:46 EDT
Received: from ietf.ietf.org by ietf.org id aa04912; 17 Jun 97 7:31 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-rapi-00.txt, .ps
Date: Tue, 17 Jun 1997 07:31:41 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706170731.aa04912 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 Resource Reservation Setup
Protocol Working Group of the IETF.
Title : RAPI -- An RSVP Application Programming Interface
Author(s) : R. Braden, D. Hoffman
Filename : draft-ietf-rsvp-rapi-00.txt, .ps
Pages : 25
Date : 06/16/1997
This memo describes version 5 of RAPI, a specific API (application
programming interface) for RSVP. The RAPI interface is one realization of
the generic API contained in the RSVP Functional Specification document,
and it is being published for information only. The RAPI interface is
based upon a client library, whose calls are described 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-rsvp-rapi-00.txt".
Or
"get draft-ietf-rsvp-rapi-00.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-rapi-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rsvp-rapi-00.txt".
Or
"FILE /internet-drafts/draft-ietf-rsvp-rapi-00.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
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: <19970616173325.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rsvp-rapi-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-rapi-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970616173325.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05554; 17 Jun 97 7:46 EDT
Received: from ietf.ietf.org by ietf.org id aa04886; 17 Jun 97 7:31 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipngwg-trans-tokenring-00.txt
Date: Tue, 17 Jun 1997 07:31:31 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706170731.aa04886 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 IPNG Working Group of the
IETF.
Title : Transmission of IPv6 Packets over Token Ring Networks
Author(s) : S. Thomas
Filename : draft-ietf-ipngwg-trans-tokenring-00.txt
Pages : 10
Date : 06/16/1997
This memo specifies the MTU and frame format for transmission of IPv6
packets on Token Ring networks. It also specifies the method of forming
IPv6 link-local addresses on Token Ring networks and the content of the
Source/Target Link-layer Address option used the Router Solicitation,
Router advertisement, Neighbor Solicitation and Neighbor Advertisement
messages when those messages are transmitted on a Token Ring network.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipngwg-trans-tokenring-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-tokenring-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipngwg-trans-tokenring-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
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: <19970616112903.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-trans-tokenring-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-trans-tokenring-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970616112903.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa10174; 17 Jun 97 12:23 EDT
Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid MAA27701; Tue, 17 Jun 1997 12:23:00 -0400 (EDT)
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <MAA12009 at pad-thai.cam.ov.com>; Tue, 17 Jun 1997 12:40:55 GMT
Message-Id: <33A7044C.CFF at frcl.bull.fr>
Date: Tue, 17 Jun 1997 14:40:28 -0700
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
Mime-Version: 1.0
To: John Linn <linn at cam.ov.com>
Cc: CAT-IETF WG <cat-ietf at mit.edu>
Subject: Re: Snego & GSS V2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
First, thanks to John Linn for providing a very good view of the various
positions. However since his mail was posted, this thread has been
pretty silent.
> ISSUE #1: Per GSS-V2/RFC-2078, there is no facility to determine in
> advance of context establishment whether or not confidentiality and
> integrity services will be available on a context, and no facility for
> callers to indicate request/requirement for these services. Addition
> of such a facility would be particularly useful in negotiated
> mechanism environments.
Since all known mechanisms support confidentiality and integrity
services, is this really an issue ? Let us not make life more
complicated than it is. :-)
> ISSUE #4: Should the snego document define the policy which is used to
> select among alternate negotiable mechanisms? Denis Pinkas believes
> so, and considers that this may be necessary in order to achieve
> interoperability. Mike Swift argued that it should not be specified
> within the document.
I would like to make a new proposal. The server will have to take into
consideration the preferences from the client, however if none of the
proposed mechanisms supports the desired options (i.e. context flags)
then the list is scanned again and the preferences are then ignored.
Thus the client will not get its options only when none of the
mechanisms support the options. With this approach we can stay with a
single list of preferences sent by the client.
At this time we have :
ContextFlags ::= BIT STRING {
delegFlag (0),
mutualFlag (1),
replayFlag (2),
sequenceFlag (3),
anonFlag (4),
Regards,
Denis
--
Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from ietf.org by ietf.org id aa10677; 17 Jun 97 12:47 EDT
Received: from ietf.ietf.org by ietf.org id aa10462; 17 Jun 97 12:39 EDT
To: IETF-Announce: ;
Subject: Reminder: Call for POC Nominations
Sender:ietf-announce-request at ietf.org
From: "(Brian E Carpenter)" <brian at hursley.ibm.com>
Reply-to: pocnom at iab.org
Date: Tue, 17 Jun 1997 12:39:14 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706171239.aa10462 at ietf.org>
IETF,
The IAB has been requested to appoint two people to the Policy
Oversight Committee (POC) established under the recently signed
DNS Memorandum of Understanding. For full details please
see http://www.iahc.org/gTLD-MoU.html
Although there is continued discussion at the political level
about these matters, the IAB has decided to proceed with these
appointments to avoid loss of time if and when the POC starts up.
One person is to be appointed for one year and a second person
for three years, to allow for rolling replacements in future.
The IAB has decided to appoint persons with strong technical
expertise in DNS and Internet technology and with a strong claim
to have an international outlook. The IAB has further decided
to make an open call for nominations from the IETF community.
Procedure:
1. This message is the call for nominations, which should be sent
to pocnom at iab.org by the closing date of 30 June 1997.
** DO NOT SEND NOMINATIONS AS A REPLY TO THIS MESSAGE; SEND THEM
TO pocnom at iab.org **
2. Each nomination must give the name, affiliation, email address
and phone number of the nominee, plus a brief statement (maximum
10 lines) about the nominee's technical and international credentials.
3. Self-nominations are allowed.
4. The IAB will verify each nominee's willingness to serve for one
or three years.
5. The list of willing nominees will be published by the IAB shortly
after the closing date. Confidential comments from the community will
be solicited. The IAB will then make its two appointments
and announce them within one month.
6. Apart from the above, the IAB will be guided in its deliberations
by the procedures defined in RFC 2027.
7. Nominees must accept that a recall procedure, analagous to that
defined in RFC 2027, may be invoked at any time during their terms.
Note - for future years, the IAB is considering delegating
this task to the normal IETF Nominating and Recall Committee
established under RFC 2027. Comments on this idea are welcome.
Brian Carpenter (IAB Chair) brian at hursley.ibm.com
Received: from ietf.org by ietf.org id aa12561; 17 Jun 97 13:52 EDT
Received: from cbgw2.lucent.com by ietf.org id aa12441; 17 Jun 97 13:45 EDT
Received: from mvjok.mv.lucent.com by cbig2.firewall.lucent.com (SMI-8.6/EMS-L sol2)
id NAA20797; Tue, 17 Jun 1997 13:39:57 -0400
Received: by mvjok.mv.lucent.com (5.x/EMS-L sol2)
id AA14117; Tue, 17 Jun 1997 13:41:02 -0400
Received: from ftfls.mv.lucent.com by mvjok.mv.lucent.com (5.x/EMS-L sol2)
id AA14092; Tue, 17 Jun 1997 13:41:00 -0400
Received: from ftfls by ftfls.mv.lucent.com (SMI-8.6/EMS-L sol2)
id NAA01537; Tue, 17 Jun 1997 13:37:20 -0400
X-Orig-Sender: ewgray at mvjok.mv.lucent.com
Message-Id: <33A6CB50.6E99 at lucent.com>
Date: Tue, 17 Jun 1997 13:37:20 -0400
Sender:ietf-request at ietf.org
From: Eric W Gray <ewgray at lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 3.01 (X11; U; SunOS 5.5 sun4u)
Mime-Version: 1.0
To: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
Cc: Craig Partridge <craig at aland.bbn.com>, ietf at ietf.org
Subject: Re: Internet capacity Japan - US exceeds phone capacity
References: <199706162011.NAA06092 at aland.bbn.com> <33A5AF9D.2471 at cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Henning Schulzrinne wrote:
>
> Craig Partridge wrote:
> >
>
> > Whether people are actually getting a discount from bandwidth
> > in bulk is, I think, less clear. I suspect discounts depend on
> > where you sit in the consumer foodchain. For example, as I
> > understand things, ISPs are buying capacity from telcos that own
> > the fiber (and unless there's some regulatory issue, I assume a
> > telco would charge an ISPs somewhat more than than what they
> > would charge their internal telephony group.
>
> An article by Jonathan Turner (at
> http://www.arl.wustl.edu/~jst/TransPrice.html) complains that the
> telcos are actually charging basically as multiples of 64 kb/s
> rather than giving volume discounts. However, this would "only"
> affect internal accounting at companies that run their own
> facilities (like KDD and MCI, I assume) instead of leasing them
> from facilities-based carriers.
>
I read the article and believe that the "multiples of 64 kb/s" is
based on regulatory mandated tarriffs for data-services at 64 kb/s.
Less recent discussions have identified TELCO - particularly long
distance providers - as having issues with these tarriffs because
they are so much lower than similar voice-based tarriffs. As I
understand it, the issue is that Internet Telephony allows users
to obtain higher-tarriff services at a lower-tarriff rate. This
implies to me that one of the driving factors leading to higher
levels of data traffic relative to voice-telephony might be the
same cost difference.
If that weren't enough, I especially recall reading that higher
savings are available via the use of Internet Telephony as an
alternative to over-seas long distance services.
> >
> > Craig
>
> Henning
--
Eric
Received: from cnri by ietf.org id aa15061; 17 Jun 97 16:27 EDT
Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA28832; Tue, 17 Jun 1997 16:26:50 -0400 (EDT)
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <SAA14065 at pad-thai.cam.ov.com>; Tue, 17 Jun 1997 18:04:55 GMT
From: mcom.list.cat-ietf at netscape.com
Date: Tue, 17 Jun 1997 11:03:06 -0700 (PDT)
Message-Id: <199706171803.LAA14130 at islay.mcom.com>
X-Authentication-Warning: islay.mcom.com: Host islay.mcom.com [198.93.92.5] didn't use HELO protocol
Apparently-To: <cat-ietf at mit.edu>
Precedence: bulk
subscribe cat-ietf
Received: from ietf.org by ietf.org id aa17160; 17 Jun 97 18:10 EDT
Received: from smtp.tele.fi by ietf.org id aa16775; 17 Jun 97 18:04 EDT
Received: from IDENT-NOT-QUERIED at www.siemens.fi (port 2201 [193.210.133.150]) by smtp.tele.fi with SMTP id <17258-7245>; Wed, 18 Jun 1997 01:00:28 +0300
Received: by www.siemens.fi(Lotus SMTP MTA v1.05 (274.9 11-27-1996)) id 422564B9.007FE042 ; Wed, 18 Jun 1997 01:05:28 +0200
X-Lotus-FromDomain: SIEMENS FINLAND
Sender:ietf-request at ietf.org
From: pekka.sahlsten at siemens.fi
To: ietf at ietf.org
Message-ID: <422564B9.002DE77C.00 at www.siemens.fi>
Date: Tue, 17 Jun 1997 11:15:29 +0200
Subject: Re: Internet capacity exceeds phone capacity
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
Pekka Sahlsten at SIEMENS FINLAND
17.06.97 11:15
>> The telecomm world will change profoundly when Internet traffic volume
is 5-10x of telephony traffic, a couple more years down the road. At that
point, the telephony network engineers will be calling on the Internet
engineers, asking for a few megabits of QoS-pipe from hither to yon to
carry legacy voice traffic. And I'm sure that the Internet engineers will
fundamentally change the business model for renting and burying fiber
capacity.
I suppose the original discussion wasn't really about VoIP, but when you
compare voice capacity to internet internet capacity, this automatically
comes to mind. With VoIP compression one can theoretically increase the
amount of carried voice traffic per circuit tenfold. To me it makes
sense to go from traditional voice circuits to VoIP eventually. Add this
to the future scenarios.
-- Pekka
Received: from ietf.org by ietf.org id aa18505; 17 Jun 97 19:43 EDT
Received: from cs.columbia.edu by ietf.org id aa18422; 17 Jun 97 19:39 EDT
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id TAA15159; Tue, 17 Jun 1997 19:34:58 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id TAA12839; Tue, 17 Jun 1997 19:34:57 -0400 (EDT)
X-Orig-Sender: hgs at cs.columbia.edu
Message-ID: <33A71F21.5A14 at cs.columbia.edu>
Date: Tue, 17 Jun 1997 19:34:57 -0400
Sender:ietf-request at ietf.org
From: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: pekka.sahlsten at siemens.fi
CC: ietf at ietf.org
Subject: Re: Internet capacity exceeds phone capacity
References: <422564B9.002DE77C.00 at www.siemens.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Most transoceanic links are already using voice/silence compression to
16 or 32 kb/s, so the gain is far less than 10 on those links.
Unfortunately, the 40-byte overhead for IPv4 packet voice means up to
100% packet header overhead, which removes the silence suppression
advantage for low bit-rate voice with acceptable delays. Obviously, IPv6
doesn't exactly help here and we won't mention AAL5/ATM. Point-to-point
low-speed links can use IP/UPD/RTP header compression, which removes
this penalty for corporate interconnects.
pekka.sahlsten at siemens.fi wrote:
>
> Pekka Sahlsten at SIEMENS FINLAND
>
> I suppose the original discussion wasn't really about VoIP, but when you
> compare voice capacity to internet internet capacity, this automatically
> comes to mind. With VoIP compression one can theoretically increase the
> amount of carried voice traffic per circuit tenfold. To me it makes
> sense to go from traditional voice circuits to VoIP eventually. Add this
> to the future scenarios.
>
> -- Pekka
--
Henning Schulzrinne email: schulzrinne at cs.columbia.edu
Dept. of Computer Science phone: +1 212 939-7042
Columbia University fax: +1 212 666-0140
New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs
Received: from cnri by ietf.org id aa18739; 17 Jun 97 20:01 EDT
Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA29662; Tue, 17 Jun 1997 20:00:32 -0400 (EDT)
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <WAA12560 at pad-thai.cam.ov.com>; Tue, 17 Jun 1997 22:51:33 GMT
Date: Tue, 17 Jun 1997 18:51:21 -0400
Message-Id: <9706172251.AA23473 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: D.Pinkas at frcl.bull.fr
Cc: John Linn <linn at cam.ov.com>, CAT-IETF WG <cat-ietf at mit.edu>
In-Reply-To: Denis Pinkas's message of Tue, 17 Jun 1997 14:40:28 -0700,
<33A7044C.CFF at frcl.bull.fr>
Subject: Re: Snego & GSS V2
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Tue, 17 Jun 1997 14:40:28 -0700
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
> ISSUE #1: Per GSS-V2/RFC-2078, there is no facility to determine in
> advance of context establishment whether or not confidentiality and
> integrity services will be available on a context, and no facility for
> callers to indicate request/requirement for these services. Addition
> of such a facility would be particularly useful in negotiated
> mechanism environments.
Since all known mechanisms support confidentiality and integrity
services, is this really an issue ? Let us not make life more
complicated than it is. :-)
Is this really true? I would be very glad if this were the case.
However, my understanding was that the DCE GSSAPI library does not
support confidentiality for export control reasons. And in France,
isn't the case that a GSSAPI library which supported confidentialty is
illegal unless it has been certified by the French Secret Service? In
any case, it was my impression that there are a number of commercial
implementations might not support confidentiality for, uh,
"non-technical" reasons.
I would like to make a new proposal. The server will have to take into
consideration the preferences from the client, however if none of the
proposed mechanisms supports the desired options (i.e. context flags)
then the list is scanned again and the preferences are then ignored.
Thus the client will not get its options only when none of the
mechanisms support the options. With this approach we can stay with a
single list of preferences sent by the client.
This seems reasonable to me.
At this time we have :
ContextFlags ::= BIT STRING {
delegFlag (0),
mutualFlag (1),
replayFlag (2),
sequenceFlag (3),
anonFlag (4),
The GSSV2 specification does define a conf_avail and integ_avail as
context flags for gss_inquire_creds. Perhaps we should extend the
definition of ContextFlags in spnego to include those flags returned by
gss_inquire_creds, with the understanding that this just expresses
preferences which may affect which mechanism is selected (although there
still can be no guarantee that the resulting security context will have
the features requested by the client); the client should still check
using gss_inquire_context() to make sure that it got what it asked for.
Is this something that people would find ameneable?
- Ted
Received: from ietf.org by ietf.org id aa04419; 18 Jun 97 7:36 EDT
Received: from ietf.ietf.org by ietf.org id aa04045; 18 Jun 97 7:14 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-armitage-ion-venus-03.txt
Date: Wed, 18 Jun 1997 07:14:38 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706180714.aa04045 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : VENUS - Very Extensive Non-Unicast Service
Author(s) : G. Armitage
Filename : draft-armitage-ion-venus-03.txt
Pages : 13
Date : 06/17/1997
The MARS model (RFC2022) provides a solution to intra-LIS IP multicasting
over ATM, establishing and managing the use of ATM pt-mpt SVCs for IP
multicast packet forwarding. Inter-LIS multicast forwarding is achieved
using Mrouters, in a similar manner to which the `Classical IP over ATM'
model uses Routers to inter-connect LISes for unicast traffic. The
development of unicast IP shortcut mechanisms (e.g. NHRP) has led some
people to request the development of a Multicast equivalent. There are a
number of different approaches. This document focuses exclusively on the
problems associated with extending the MARS model to cover multiple
clusters or clusters spanning more than one subnet. It describes a
hypothetical solution, dubbed `Very Extensive NonUnicast Service' (VENUS),
and shows how complex such a service would be. It is also noted that VENUS
ultimately has the look and feel of a single, large cluster using a
distributed MARS. This document is being issued to help focus ION efforts
towards alternative solutions for establishing ATM level multicast
connections between LISes.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-armitage-ion-venus-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-armitage-ion-venus-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-armitage-ion-venus-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970617171020.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-armitage-ion-venus-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-armitage-ion-venus-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970617171020.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04420; 18 Jun 97 7:36 EDT
Received: from ietf.ietf.org by ietf.org id aa04023; 18 Jun 97 7:14 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: receipt 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-receipt-mdn-04.txt
Date: Wed, 18 Jun 1997 07:14:22 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706180714.aa04023 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 Receipt Notifications for
Internet Mail Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : An Extensible Message Format for Message Disposition
Notifications
Author(s) : R. Fajman
Filename : draft-ietf-receipt-mdn-04.txt
Pages : 30
Date : 06/17/1997
This memo defines a MIME content-type that may be used by a mail user agent
(UA) or electronic mail gateway to report the disposition of a message
after it has been sucessfully delivered to a recipient. This content-type
is intended to be machine-processable. Additional message headers are also
defined to permit Message Disposition Notifications (MDNs) to be requested
by the sender of a message. The purpose is to extend Internet Mail to
support functionality often found in other messaging systems, such as X.400
and the proprietary "LAN-based" systems, and often referred to as "read
receipts," "acknowledgements," or "receipt notifications." The intention
is to do this while respecting the privacy concerns that have often been
expressed when such functions have been discussed in the past. Because
many messages are sent between the Internet and other messaging systems
(such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is
designed to be useful in a multi-protocol messaging environment. To this
end, the protocol described in this memo provides for the carriage of
"foreign" addresses, in addition to those normally used in Internet Mail.
Additional attributes may also be
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-receipt-mdn-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-receipt-mdn-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-receipt-mdn-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970617095337.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-receipt-mdn-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-receipt-mdn-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970617095337.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05997; 18 Jun 97 8:54 EDT
Received: from ietf.ietf.org by ietf.org id aa05876; 18 Jun 97 8:49 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: IMAP4 Login Referrals to Proposed Standard
Reply-to: iesg at ietf.org
Date: Wed, 18 Jun 1997 08:49:07 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706180849.aa05876 at ietf.org>
The IESG has received a request to consider IMAP4 Login Referrals
<draft-gahrns-imap-login-referrals-00.txt> as a Proposed Standard.
This has been reviewed in the IETF but is not the product of an IETF
Working Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by July 18, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa06389; 18 Jun 97 9:11 EDT
Received: from ietf.ietf.org by ietf.org id aa06304; 18 Jun 97 9:08 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: IMAP4 Mailbox Referrals to Proposed Standard
Reply-to: iesg at ietf.org
Date: Wed, 18 Jun 1997 09:08:09 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9706180908.aa06304 at ietf.org>
The IESG has received a request to consider IMAP4 Mailbox Referrals
<draft-gahrns-imap-mailbox-referral-00.txt> as a Proposed Standard.
This has been reviewed in the IETF but is not the product of an IETF
Working Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by July 18, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from cnri by ietf.org id aa18369; 18 Jun 97 17:16 EDT
Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA02266; Wed, 18 Jun 1997 17:16:00 -0400 (EDT)
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <TAA10341 at pad-thai.cam.ov.com>; Wed, 18 Jun 1997 19:47:14 GMT
Message-Id: <199706181947.PAA07562 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Administrative: scheduling for Munich CAT session
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 18 Jun 1997 15:47:06 -0400
From: John Linn <linn at cam.ov.com>
Precedence: bulk
I've just received the following information from the IETF secretariat,
and hereby forward:
> This is to confirm CAT has been changed to the following:
>
> Wednesday, August 13 at 1530-1730 (opposite asid, snmpv3, mpls)
This will be reflected in the next draft of the IETF-level agenda.
--jl
Received: from cnri by ietf.org id aa20842; 18 Jun 97 19:43 EDT
Received: from external.BSDI.COM (external.BSDI.COM [205.230.225.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid TAA02626 for <IETF-archive at cnri.reston.va.us>; Wed, 18 Jun 1997 19:42:33 -0400 (EDT)
Received: (from daemon at localhost)
by external.BSDI.COM (8.8.5/8.8.5) id RAA15913
for telnet-ietf-list at bsdi.com; Wed, 18 Jun 1997 17:37:50 -0600 (MDT)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
by external.BSDI.COM (8.8.5/8.8.5) with SMTP id RAA15910
for <telnet-ietf at bsdi.com>; Wed, 18 Jun 1997 17:37:49 -0600 (MDT)
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA02681; Wed, 18 Jun 97 19:37:47 EDT
Received: by dcl.MIT.EDU (5.x/4.7) id AA24447; Wed, 18 Jun 1997 19:37:46 -0400
Date: Wed, 18 Jun 1997 19:37:46 -0400
Message-Id: <9706182337.AA24447 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Keith Moore <moore at cs.utk.edu>
Cc: telnet-ietf at bsdi.com
In-Reply-To: Keith Moore's message of Mon, 16 Jun 1997 16:45:11 -0400,
<199706162045.QAA15391 at spot.cs.utk.edu>
Subject: Re: Last Call: Telnet Comport Control Option to Proposed Standard
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Mon, 16 Jun 1997 16:45:11 -0400
From: Keith Moore <moore at cs.utk.edu>
Hi. I'd like to know what telnet implementors think of this,
if there are any problems with it, etc.
Well, it takes telnet down a path which I don't think it was ever
intended for, but I can't think of any really cogent reasons why it's a
bad idea. I expect this is going to be one of the really rarely
implemented telnet options, so the relative value in standardizing it
may be low; however, I can't think of any downsides of blessing it as a
proposed standard --- so why not?
- Ted
Received: from cnri by ietf.org id aa21235; 18 Jun 97 20:01 EDT
Received: from external.BSDI.COM (external.BSDI.COM [205.230.225.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA02659 for <IETF-archive at cnri.reston.va.us>; Wed, 18 Jun 1997 20:00:50 -0400 (EDT)
Received: (from daemon at localhost)
by external.BSDI.COM (8.8.5/8.8.5) id RAA16673
for telnet-ietf-list at bsdi.com; Wed, 18 Jun 1997 17:57:24 -0600 (MDT)
Received: from puli.cisco.com (puli.cisco.com [171.69.1.174])
by external.BSDI.COM (8.8.5/8.8.5) with SMTP id RAA16670
for <telnet-ietf at bsdi.com>; Wed, 18 Jun 1997 17:57:23 -0600 (MDT)
Received: (billw at localhost) by puli.cisco.com (8.6.12/8.6.5) id QAA21445; Wed, 18 Jun 1997 16:56:18 -0700
Date: Wed, 18 Jun 97 16:56:18 PDT
From: William Chops Westfield <billw at cisco.com>
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Cc: Keith Moore <moore at cs.utk.edu>, telnet-ietf at bsdi.com
Subject: Re: Last Call: Telnet Comport Control Option to Proposed Standard
In-Reply-To: Your message of Wed, 18 Jun 1997 19:37:46 -0400
Message-ID: <CMM.0.90.2.866678178.billw at puli.cisco.com>
I found it annoying in a a layering sense. We implemented it to allow
remote modems to be used for FAX. What would have made sense is a FAX
telnet option. But of course, no software would actually support fax
over telnet anyway - they all support fax over some modem. So now we
have a PC connected to an ethernet connected to an internet connected to
an access server with digital modems, and there is NO DTR, CTS, RTS, or
any of that ANYWHERE in that path, but we have code to simulate it in
telnet options so that FAX software can run without knowing that it's
going over such a convoluted path....
Other than that, it's ok, I guess.
BillW
Received: from cnri by ietf.org id aa04366; 19 Jun 97 8:10 EDT
Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid IAA03405; Thu, 19 Jun 1997 08:09:24 -0400 (EDT)
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <KAA28928 at pad-thai.cam.ov.com>; Thu, 19 Jun 1997 10:07:57 GMT
Message-Id: <33A98372.75BD at frcl.bull.fr>
Date: Thu, 19 Jun 1997 12:07:30 -0700
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
Mime-Version: 1.0
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Cc: John Linn <linn at cam.ov.com>, CAT-IETF WG <cat-ietf at mit.edu>
Subject: Re: Snego & GSS V2
References: <9706172251.AA23473 at dcl.MIT.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
> Since all known mechanisms support confidentiality and integrity
> services, is this really an issue ? Let us not make life more
> complicated than it is. :-)
>
> Is this really true? I would be very glad if this were the case.
> However, my understanding was that the DCE GSSAPI library does not
> support confidentiality for export control reasons. And in France,
> isn't the case that a GSSAPI library which supported confidentialty is
> illegal unless it has been certified by the French Secret Service? In
> any case, it was my impression that there are a number of commercial
> implementations might not support confidentiality for, uh,
> "non-technical" reasons.
You are right to say that confidentiality might not be available for
"non technical" reasons. However the caller should better know whether
he will get confidentiality with a 40 bits key or a 128 bits key. So
conf_avail alone is not that useful. SPNEGO allows the use of OIDs which
define *all* the algorithms used including the confidentiality
algorithm. So the caller of GSS-APIs had better to select the OIDs for
the negotiation which are adequate for the level of privacy he is
looking for.
Looking at the problem this way, we do not need anything else.
(...)
> The GSSV2 specification does define a conf_avail and integ_avail as
> context flags for gss_inquire_creds.
Sorry. It does not. However, the GSSV2 specification does define a
conf_avail and integ_avail as context flags for gss_inquire_context. I
guess you made a typo.
> Perhaps we should extend the
> definition of ContextFlags in spnego to include those flags returned by
> gss_inquire_creds, with the understanding that this just expresses
> preferences which may affect which mechanism is selected (although there
> still can be no guarantee that the resulting security context will have
> the features requested by the client); the client should still check
> using gss_inquire_context() to make sure that it got what it asked for.
I am confused about what you are saying. Would you rephrase the whole
story to make sure whether you speak of gss_inquire_creds() and/or
gss_inquire_context() ?
Denis
--
Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from cnri by ietf.org id aa09689; 19 Jun 97 11:34 EDT
Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA04001; Thu, 19 Jun 1997 11:33:38 -0400 (EDT)
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <NAA17367 at pad-thai.cam.ov.com>; Thu, 19 Jun 1997 13:28:10 GMT
Message-Id: <199706191327.AA11483 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: Snego & GSS V2
To: D.Pinkas at frcl.bull.fr
Date: Thu, 19 Jun 1997 09:26:40 -0400 (EDT)
Cc: cat-ietf at mit.edu
In-Reply-To: <33A98372.75BD at frcl.bull.fr> from "Denis Pinkas" at Jun 19, 97 12:07:30 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Denis Pinkas wrote:
>
> > Since all known mechanisms support confidentiality and integrity
> > services, is this really an issue ? Let us not make life more
> > complicated than it is. :-)
> >
> > Is this really true? I would be very glad if this were the case.
> > However, my understanding was that the DCE GSSAPI library does not
> > support confidentiality for export control reasons. And in France,
> > isn't the case that a GSSAPI library which supported confidentialty is
> > illegal unless it has been certified by the French Secret Service? In
> > any case, it was my impression that there are a number of commercial
> > implementations might not support confidentiality for, uh,
> > "non-technical" reasons.
>
> You are right to say that confidentiality might not be available for
> "non technical" reasons. However the caller should better know whether
> he will get confidentiality with a 40 bits key or a 128 bits key. So
> conf_avail alone is not that useful. SPNEGO allows the use of OIDs which
> define *all* the algorithms used including the confidentiality
> algorithm. So the caller of GSS-APIs had better to select the OIDs for
> the negotiation which are adequate for the level of privacy he is
> looking for.
>
> Looking at the problem this way, we do not need anything else.
I still disagree.
The purpose of the "Generic" Security Services is that it requires
no (few) changes for the application implementation and the purpose
of the "portable" applications approach is that it requires both
no (few) changes to the implementation AND the administration/configuration
of the application.
I think it is a very bad idea to have to configure the characteristics
of each individually installed mechanism to be configured into each and
every single application in the form of OIDs!
Concerning the strengths of mechanisms; this is not necessarily the
only characteristic that is important. Whether a 3DES Kerberos is
more secure than a 3DES SPKM (-like?) mechanism is probably more a
religious than a technical issue, but whether prot_ready is available
or not (1- or 2-way authentication versus 3-way authentication) can
be a critical technical issue.
With the current approach the result of the negotiation strongly relies
on (a) each and every application provider to offer enough and usable
means for configuration of OID-Lists and (b) the user to fully understand
the characteristics and technical details and (c) that the user correctly
maps the features offered by all his mechanisms to the individual
features important to the differing specific needs of each and every
application and respectively enter them differently but correctly into
differing configuration dialogs and files of those various applications.
Really, I think we could do much better by centralizing all the
configuration stuff into the negotiation mechanism.
I consider the possibility to supply a OID_set of a mechanism
preference list much to awkward to be useful. Just imagine how
easy it would be for existing GSS-API based applications to
add a single call just before gss_init_sec_context() to
tell the negotiation mechanism which features are urgently
required for (smooth/best) operation while still asking for
regular nice-to-have features during gss_init_sec_context().
-Martin
Received: from cnri by ietf.org id aa15057; 19 Jun 97 16:13 EDT
Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA04867; Thu, 19 Jun 1997 16:12:40 -0400 (EDT)
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <SAA17057 at pad-thai.cam.ov.com>; Thu, 19 Jun 1997 18:27:45 GMT
Date: Thu, 19 Jun 1997 14:27:20 -0400
Message-Id: <9706191827.AA25206 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: D.Pinkas at frcl.bull.fr
Cc: "Theodore Y. Ts'o" <tytso at mit.edu>, John Linn <linn at cam.ov.com>,
CAT-IETF WG <cat-ietf at mit.edu>
In-Reply-To: Denis Pinkas's message of Thu, 19 Jun 1997 12:07:30 -0700,
<33A98372.75BD at frcl.bull.fr>
Subject: Re: Snego & GSS V2
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Thu, 19 Jun 1997 12:07:30 -0700
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
You are right to say that confidentiality might not be available for
"non technical" reasons. However the caller should better know whether
he will get confidentiality with a 40 bits key or a 128 bits key. So
conf_avail alone is not that useful. SPNEGO allows the use of OIDs which
define *all* the algorithms used including the confidentiality
algorithm. So the caller of GSS-APIs had better to select the OIDs for
the negotiation which are adequate for the level of privacy he is
looking for.
Denis,
You're making the assumption that knowledge of the algorithms
and capabilities of the various mechanisms are available to both
end-points during the negotiation phase. It's not clear to me that this
is a good assumption.
In particular, I believe it is currently possible to implement a
Kerberos mechanism which uses the Kerberos GSSAPI Mechanism OID, but
which does not support confidentiality. This is not outlawed by the
specification; hence, just because you know a particular Mechanism OID
is supported by the client or the server doesn't mean that you know
whether or not that particular mechanism supports confidentiality or
not.
I think the real problem here is that we have a disconnect in
our assumption about how much information is carried in an OID.
> The GSSV2 specification does define a conf_avail and integ_avail as
> context flags for gss_inquire_creds.
Sorry. It does not. However, the GSSV2 specification does define a
conf_avail and integ_avail as context flags for gss_inquire_context. I
guess you made a typo.
Yes, this is a typo. Sorry about that; as you guessed, I meant
"gss_inquire_context".
> Perhaps we should extend the
> definition of ContextFlags in spnego to include those flags returned by
> gss_inquire_creds, with the understanding that this just expresses
> preferences which may affect which mechanism is selected (although there
> still can be no guarantee that the resulting security context will have
> the features requested by the client); the client should still check
> using gss_inquire_context() to make sure that it got what it asked for.
I am confused about what you are saying. Would you rephrase the whole
story to make sure whether you speak of gss_inquire_creds() and/or
gss_inquire_context() ?
Please replace "gss_inquire_creds" with "gss_inquire_context" my above
text. The basic idea of what I'm suggesting is that the client should
be able to make a request (via the conf_avail and integ_avail flags) to
the server that it would like confidentialty or integrity services. To
do this, we need to extend the definition of ContextFlags in spnego to
include these two flags. In other words, I'm asking for an extra two
bits. Surely we can spare those two bits, can't we? :-)
Of course, since these bits are not protected, and since an spnego
acceptor might conceivably decide to ignore this request, the client
would still have to check using gss_inquire_context to make sure that
confidentialty and integrity services are available in the context after
it has been established. It merely serves as a way for the client to
make its preference known to the server.
This is of course not a perfect solution --- as you point out, this
doesn't distinguish between a 40-bit sham encryption and a strong
128-bit cypher. Nevertheless, it seems to me that this is better than
not allowing the client any ability to indicate a preference about
whether it would desire confidentiality or integrity services.
- Ted
Received: from ietf.org by ietf.org id aa15131; 19 Jun 97 16:19 EDT
Received: from zephyr.isi.edu by ietf.org id aa14724; 19 Jun 97 15:56 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
id <AA06799>; Thu, 19 Jun 1997 12:52:29 -0700
Message-Id: <199706191952.AA06799 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2166 on APPN Implementer's Workshop/ DLSw v2.0 Enhancements
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 19 Jun 97 12:52:29 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 2166:
Title: APPN Implementer's Workshop Closed Pages Document
DLSw v2.0 Enhancements
Author: D. Bryant, P. Brittain
Date: June 1997
Mailbox: David_Bryant at 3mail.3com.com, pjb at datcon.co.uk
Pages: 34
Characters: 75527
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2166.txt
This document specifies a set of extensions to RFC 1795 designed to
improve the scalability of DLSw. It also specifies clarifications to
RFC 1795 in the light of the implementation experience to-date.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970619124754.RFC at ISI.EDU>
SEND /rfc/rfc2166.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2166.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970619124754.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17211; 19 Jun 97 18:50 EDT
Received: from igw3.watson.ibm.com by ietf.org id aa17113; 19 Jun 97 18:44 EDT
Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id SAA16682; Thu, 19 Jun 1997 18:32:57 -0400
Received: from tapti.watson.ibm.com (tapti.watson.ibm.com [9.2.19.17]) by mailhub1.watson.ibm.com (8.8.2/05-30-97) with SMTP id SAA43614; Thu, 19 Jun 1997 18:33:10 -0400
Received: by tapti.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96)
id AA18850; Thu, 19 Jun 1997 18:33:09 -0400
Date: Thu, 19 Jun 1997 18:33:09 -0400
Sender:ietf-request at ietf.org
From: Debanjan Saha <debanjan at watson.ibm.com>
Message-Id: <9706192233.AA18850 at tapti.watson.ibm.com>
To: end2end-interest at isi.edu, tccc at cs.umass.edu, int-serv at isi.edu,
ietf at ietf.org, rem-conf-request at es.net, ieee_rtc_list at cs.tamu.edu
Subject: CFP: JHSN special issue on Multimedia Networking
Cc: debanjan at watson.ibm.com, tripathi at engr.ucr.edu
Source-Info: From (or Sender) name not authenticated.
Please feel free to circulate the CFP by any means you deem
appropriate. Also, please excuse any multiple copies of this
CFP you may receive due to your memberships in multiple mailing
lists.
CALL FOR PAPERS
----------------------------------------------------------------------------
JOURNAL OF HIGH SPEED NETWORKS
Special Issue On
Multimedia Networking
-----------------------------------------------------------------------------
The rapid proliferation of multimedia applications has severely
strained an already overloaded networking infrastructure. In order
to foster an environment for ubiquitous deployment of multimedia
applications, it is imperative that we design and implement the next
generation of network protocols and services that provide scalable
end-to-end support to networked multimedia applications. The purpose
of this journal issue is to report on the latest technological
advances that will enable the development of such an infrastructure.
The journal is looking for contributions in the following areas:
o RSVP and integrated services in the Internet
o Queue management in routers and switches
o QoS signaling and routing in IP and ATM networks
o Audio/Video streaming, push and pull technologies
o Multicasting and media scaling, rate control
o Network conscious/adaptive applications and protocols
o Application level framing, customizable protocol features
o New applications, experimental protocols and systems
o Multimedia over cable modems/xDSL, wireless/satellite links
o Traffic analysis, performance modeling and evaluation
Important Dates:
Paper submission deadline: October 31, 1997.
First Round of Reviews: February 15, 1998
Acceptance Notification: March 30, 1998
Expected Publication Date: Summer, 1998
Please submit 4 copies of your paper to the editors of the special issue:
Satish K. Tripathi Debanjan Saha
Dean and Johnson Chair Professor Research Staff Member
Bourns College of Engineering Room# H3-D32
University of California IBM T.J. Watson Research Center
Riverside, CA 92521-0425 Hawthorne, NY 10532
Phone: (909) 787-6374 Phone: (914) 784-7194
Fax: (909) 787-3188 Fax: (914) 784-6205
Email: tripathi at engr.ucr.edu Email: debanjan at watson.ibm.com
--------------------------------------------------------------------------------
Editorial Board of JHSN
Editor-in-Chief
Professor Deepinder Sidhu
Maryland Center for Telecommunications Research
Department of Computer Science and Electrical Engineering
University of Maryland Baltimore County
Telephone: 410-455-3028
Fax: 410-455-3969
Email: sidhu at cs.umbc.edu
Editorial Board Members
Anthony Acampora(University of California, San Diego)
Subrata Banerjee (Stevens Institute of Technology)
Anthony Chung (Depaul University)
Fow-Sen Choa (University of Maryland Baltimore County)
Rene L. Cruz (University of California, San Diego)
J.J. Garcia-Luna-Aceves(University of California, Santa Cruz)
Inder Gopal (IBM T.J. Watson Research Center)
Roch Guerin (IBM T.J. Watson Research Center)
Cesar Johnston (NEC)
Michael C. Hluchyj (Summa Four, Inc.)
Raj Jain (Ohio State University)
Srinivasan Keshav (Cornell University)
Leonard Kleinrock (University of California, Los Angeles)
Arvind Krishna (IBM T. J. Watson Research Center)
Srikantha Kumar (Northwestern University)
L. Landweber (University of Wisconsin)
Brad Makrucki (IBM)
Debasis Mitra (AT&T Bell Laboratories)
Howard Motteler (UMBC)
Biswanath Mukherjee (University of California, Davis)
Kinji Ono (National Center for Science Information Systems, Japan)
Abhey Parekh (Sun Microsystems)
Steve Pink (SICS,Sweden)
Neil Ransom Bell South Communications
Norio Shiratori (Tohoku University, Japan)
Dinkar Sitaram (IBM T.J. Watson Research Center)
Jonathan M. Smith (University of Pennsylvania)
O. Spaniol (Technical University Aachen, Germany)
Martha Steenstrup (BBN Systems and Technologies)
James Sterbenz (GTE Laboratories)
Fouad Tobagi (Stanford University)
Satish K. Tripathi (University of California, Riverside)
Richard Watson (Lawrence Livermore National Laboratory)
Ellen W. Zegura (Georgia Tech)
PUBLISHER: IOS Press, Netherlands
Received: from cnri by ietf.org id aa04392; 20 Jun 97 8:22 EDT
Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid IAA06037; Fri, 20 Jun 1997 08:21:43 -0400 (EDT)
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <IAA05798 at pad-thai.cam.ov.com>; Fri, 20 Jun 1997 08:28:51 GMT
Message-Id: <33AABDAE.361D at frcl.bull.fr>
Date: Fri, 20 Jun 1997 10:28:14 -0700
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
Mime-Version: 1.0
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Cc: CAT-IETF WG <cat-ietf at mit.edu>
Subject: Re: Snego & GSS V2
References: <9706191827.AA25206 at dcl.MIT.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
I would guess Ted *meant* in his E-mail from June, 17 th:
"The GSSV2 specification does [not] define a conf_avail and integ_avail
as context flags for gss_init_sec_context [and not for
gss_inquire_creds]. Perhaps we should extend the definition of
ContextFlags in spnego to include those flags returned by
gss_inquire_context [and not by gss_inquire_creds], with the
understanding that this just expresses preferences which may affect
which mechanism is selected (although there still can be no guarantee
that the resulting security context will have the features requested by
the client); the client should still check using gss_inquire_context()
[or gss_init_sec_context] to make sure that it got what it asked for."
If this is the right correction, then I could agree with him. This makes
a small change to the Base GSS-APIs. As he said, this is not a perfect
solution ... since the perfect solution is to use mechanisms OIDs. :-)
However, if this may solve the concern from Martin, I would be ready to
accept this so that we can finally progress the document to the next
stage.
Denis
--
Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from cnri by ietf.org id aa07709; 20 Jun 97 12:02 EDT
Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid MAA06765; Fri, 20 Jun 1997 12:01:10 -0400 (EDT)
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <MAA24306 at pad-thai.cam.ov.com>; Fri, 20 Jun 1997 12:13:23 GMT
Date: Fri, 20 Jun 1997 09:13:13 -0300 (ADT)
From: Peter Michaud <pmichaud at asg.unb.ca>
To: cat-ietf at mit.edu
Subject: cat-ietf-request at mit.edu
Message-Id: <Pine.A32.3.96.970620091240.17805A-100000 at angus.ASG.unb.ca>
Organization: Atlantic Systems Group
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk
cat-ietf-request at mit.edu
-------------------------------------------
Peter D. Michaud
Software Developer
ATLANTIC SYSTEMS GROUP
COGITO EGGO SUM
(I think, therefore I am a waffle)
-------------------------------------------
Received: from cnri by ietf.org id aa12926; 20 Jun 97 18:17 EDT
Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA07957; Fri, 20 Jun 1997 18:16:40 -0400 (EDT)
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <QAA20338 at pad-thai.cam.ov.com>; Fri, 20 Jun 1997 16:39:19 GMT
Date: Fri, 20 Jun 1997 12:39:14 -0400
Message-Id: <9706201639.AA25836 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: D.Pinkas at frcl.bull.fr
Cc: "Theodore Y. Ts'o" <tytso at mit.edu>, CAT-IETF WG <cat-ietf at mit.edu>
In-Reply-To: Denis Pinkas's message of Fri, 20 Jun 1997 10:28:14 -0700,
<33AABDAE.361D at frcl.bull.fr>
Subject: Re: Snego & GSS V2
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Fri, 20 Jun 1997 10:28:14 -0700
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
I would guess Ted *meant* in his E-mail from June, 17 th:
"The GSSV2 specification does [not] define a conf_avail and integ_avail
as context flags for gss_init_sec_context [and not for
gss_inquire_creds]. Perhaps we should extend the definition of
ContextFlags in spnego to include those flags returned by
gss_inquire_context [and not by gss_inquire_creds], with the
understanding that this just expresses preferences which may affect
which mechanism is selected (although there still can be no guarantee
that the resulting security context will have the features requested by
the client); the client should still check using gss_inquire_context()
[or gss_init_sec_context] to make sure that it got what it asked for."
No,
That's not what I meant. What I meant to say was that the GSSV2
specification does define a conf_avail and integ_avail in
gss_inquire_context.
I'm suggesting that we can add these two flags to the SPNego
draft *without* necessarily adding them to gss_init_sec_context. I
agree with Denis that eventually this would be a good change to make to
the base GSSAPI drafts. However, I believe we can reserve two bits in
the SPNego document without first making that change in the base GSSAPI
drafts. The flags in SPNego do *not* have to match with the
flags in GSSAPI's gss_init_sec_context(). I am argueing that the flags
in SPNego be a superset of the context flags in gss_init_sec_context().
- Ted
Received: from ietf.org by ietf.org id aa12992; 20 Jun 97 18:21 EDT
Received: from zephyr.isi.edu by ietf.org id aa12666; 20 Jun 97 18:03 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
id <AA08667>; Fri, 20 Jun 1997 14:59:03 -0700
Message-Id: <199706202159.AA08667 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2165 on Service Location Protocol
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 20 Jun 97 14:59:03 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 2165:
Title: Service Location Protocol
Author: J. Veizades, E. Guttman, C. Perkins, S. Kaplan
Date: June 1997
Mailbox: veizades at home.com, Erik.Guttman at eng.sun.com,
cperkins at Corp.sun.com, scott at catch22.com
Pages: 72
Characters: 169889
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2165.txt
The Service Location Protocol provides a scalable framework for
the discovery and selection of network services. Using this
protocol, computers using the Internet no longer need so much static
configuration of network services for network based applications. This
document is a product of the Service Location Protocol 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 IETF.ORG. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970620145046.RFC at ISI.EDU>
SEND /rfc/rfc2165.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2165.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970620145046.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12994; 20 Jun 97 18:21 EDT
Received: from zephyr.isi.edu by ietf.org id aa12801; 20 Jun 97 18:11 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
id <AA09200>; Fri, 20 Jun 1997 15:07:04 -0700
Message-Id: <199706202207.AA09200 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2167 on RWhois Protocol
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 20 Jun 97 15:07:04 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 2167:
Title: Referral Whois (RWhois) Protocol V1.5
Author: S. Williamson, M. Kosters, D. Blacka,
J. Singh, K. Zeilstra
Date: June 1997
Mailbox: scottw at rwhois.net, markk at internic.net,
davidb at rwhois.net, jasdips at rwhois.net,
kzeil at rwhois.net
Pages: 69
Characters: 136355
Obsoletes: 1714
URL: ftp://ds.internic.net/rfc/rfc2167.txt
This memo describes Version 1.5 of the client/server interaction of
RWhois. RWhois provides a distributed system for the discovery,
retrieval, and maintenance of directory information.
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 IETF.ORG. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970620150030.RFC at ISI.EDU>
SEND /rfc/rfc2167.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2167.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970620150030.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa04618; 23 Jun 97 8:31 EDT
Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid IAA10141; Mon, 23 Jun 1997 08:30:47 -0400 (EDT)
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <IAA08436 at pad-thai.cam.ov.com>; Mon, 23 Jun 1997 08:03:32 GMT
Message-Id: <33AEAC51.9E7 at frcl.bull.fr>
Date: Mon, 23 Jun 1997 10:03:13 -0700
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.01 [fr] (Win16; I)
Mime-Version: 1.0
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Cc: CAT-IETF WG <cat-ietf at mit.edu>
Subject: Re: Snego & GSS V2
References: <9706201639.AA25836 at dcl.MIT.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
> That's not what I meant. What I meant to say was that the GSSV2
> specification does define a conf_avail and integ_avail in
> gss_inquire_context.
> I'm suggesting that we can add these two flags to the SPNego
> draft *without* necessarily adding them to gss_init_sec_context.
This is fine ... but the question is which API will set these two flags.
> I agree with Denis that eventually this would be a good change to make to
> the base GSSAPI drafts.
This would be my preferred solution, that maintains compatibility
backward
with GSS-APIs V1.
> However, I believe we can reserve two bits in
> the SPNego document without first making that change in the base GSSAPI
> drafts.
The major question is not to send these two bits in the protocol, but
once again to set them. A special API defined in SPNEGO just for that
purpose does not seem to me the best approach.
Denis
--
Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from ietf.org by ietf.org id aa11476; 23 Jun 97 15:02 EDT
Received: from gwarlinet.hmhs.com by ietf.org id aa11050; 23 Jun 97 14:38 EDT
Received: by GWARLINET.hmhs.com; id NAA10956; Mon, 23 Jun 1997 13:20:56 -0400 (EDT)
Received: from unknown(167.99.69.126) by GWARLINET.hmhs.com via smap (3.2)
id xma010911; Mon, 23 Jun 97 13:20:51 -0400
Received: from svarlexc01.hmhs.com (unverified [167.99.69.110]) by gwarlmime.hmhs.com
(Integralis SMTPRS 2.02) with SMTP id <B0000061950 at gwarlmime.hmhs.com>;
Mon, 23 Jun 1997 11:56:42 -0700
Received: by svarlexc01.hmhs.com with Microsoft Exchange (IMC 4.0.837.3)
id <01BC7FCD.93575A50 at svarlexc01.hmhs.com>; Mon, 23 Jun 1997 12:04:17 -0500
Message-Id: <c=US%a=_%p=hmhs%l=HMHS/TEXAS/0007486E at svarlexc01.hmhs.com>
Sender:ietf-request at ietf.org
From: "Stewart, Dave" <DaveStewart at hmhs.com>
To: 'IETF' <ietf at ietf.org>
Subject: FW: ISP!
Date: Mon, 23 Jun 1997 12:09:00 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
I appoligize if this is not the appropriate forum, but the sort of trash
(see msg below) herein is really below-the-belt marketing and ISPs need
to be aware. Are our cyber-hands tied from this sort of unethical
approach? Unfortunately, I'm on an MS-Mail system and can't see the
full header info. I suspect it will be invisible to you as well.
Perhaps someone else rec'd a clean SMTP copy.
-Dave
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#ifndef disclaimer
"Opinions expressed are my own and do not necessarily reflect
those of my employer." Anon
#endif
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David B. Stewart
Lead Network Engineer
Harris Methodist Health Services
----------
From: 23 at utah.com
To: Nell at Maeain.com
Subject: ISP!
Date: Sunday, June 22, 1997 5:03AM
Let us market your service/products for you. No autoresponder
responses,
just real people, responding to your ad.
We will send your personal ad, directing the receiver to a return e-mail
address, autoresponder or web site. Only real people, who read your
message, will be able to respond.
If you receive any complaints, the complainants can not send the true
header, showing where the message originated, which will protect you
from losing your ISP. The ISP's require the headers to be sent with the
message, in order to take action against you. This can not be done as
we are sending the message with our headers. YOU ARE PROTECTED!!!
We take all the risk, not YOU.
Our addresses are extracted daily and we have millions. We maintain a
remove list. This is another added feature. Therefore only those, who
have not requested their names be removed, will be used. Our remove
list
is updated daily by those who use our service. We do ask for anyone's
name, who responds to your ad and has ask to be removed, so we can keep
an
updated list at all times.
$150 for 1,000,000 sent.
Our clients are very satisfied with the service we provide and
I know you will too. You have probably received some of our mailings.
We only accept checks. Once your check has cleared the bank, we will
notify you and begin the mailing. We do not write or critique
ads. You must provide us with your copy ready message. Our mailing
lists
are not targeted. If you want us to send to a targeted group, you must
provide the targeted list. If we have to extract a targeted list, then
e-mail for prices.
If you are interested, contact us at teamwork at 1stfamily.com
Type ISP in the subject line.
BRS Services
904-282-6987
Received: from ietf.org by ietf.org id aa12142; 23 Jun 97 15:39 EDT
Received: from pax.cavebear.com by ietf.org id aa12071; 23 Jun 97 15:36 EDT
Received: from localhost (karl at localhost)
by pax.cavebear.com (8.8.5/8.8.5) with SMTP id MAA05815;
Mon, 23 Jun 1997 12:32:24 -0700 (PDT)
Date: Mon, 23 Jun 1997 12:32:23 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Karl Auerbach <karl at cavebear.com>
Reply-To: karl at cavebear.com
To: "Stewart, Dave" <DaveStewart at hmhs.com>
cc: 'IETF' <ietf at ietf.org>
Subject: Re: FW: ISP!
In-Reply-To: <c=US%a=_%p=hmhs%l=HMHS/TEXAS/0007486E at svarlexc01.hmhs.com>
Message-ID: <Pine.SOL.3.96.970623122056.5804A-100000 at pax.cavebear.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Most people who talk about the spam issue focus on the damage to the
recipients.
What is not discussed is the fact that many spammers relay their traffic,
often using forged headers and invalid in-addr.arpa reverse DNS servers,
through the computers of innocent third parties, often making unauthorized
use of mailing lists, such as this one.
As such, it is my opinion, that such spammers are profit making
enterprises engaged in interstate commerce which operate knowingly and
intentionally to make unauthorized use of third party computers to
disseminate their materials. It wouldn't be too far for me to come to the
opinion that such spammers are organized criminals and should be
prosecuted as such.
However, for that to happen, those with standing, i.e. the operators of
the third party systems which are used (such as CNRI in the case of the
IETF mailing list) need to make formal complaints to their law enforcement
agencies.
In the meantime, people should make sure that they are running the latest
sendmail releases and inserting as many filters as they can both to block
direct traffic from the spammers and to prevent relaying.
In addition, since spammers reap many of their email addresses by means of
web robots, I encourage everyone to build many pages full of absolutely
bogus mailto URLs. This will eventually pollute the spammer's mailing
lists and reduce their commercial value. Such pages should be as innocent
looking as possible; they should not contain the word "spam" nor any
trigger email addresses that could clue-in a robot that the page contains
junk email addresses.
There are other anti spam techniques.
Beware, however, that the spammers organization has made less than veiled
threats to invoke various forms of "cyberterrorists" (my term) from
various countries (especially Germany) on those who they consider
non-friendly.
--karl--
> I appoligize if this is not the appropriate forum, but the sort of trash
> (see msg below) herein is really below-the-belt marketing and ISPs need
> to be aware. Are our cyber-hands tied from this sort of unethical
> approach? Unfortunately, I'm on an MS-Mail system and can't see the
> full header info. I suspect it will be invisible to you as well.
> Perhaps someone else rec'd a clean SMTP copy.
> -Dave
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> #ifndef disclaimer
> "Opinions expressed are my own and do not necessarily reflect
> those of my employer." Anon
> #endif
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> David B. Stewart
> Lead Network Engineer
> Harris Methodist Health Services
>
> ----------
> From: 23 at utah.com
> To: Nell at Maeain.com
> Subject: ISP!
> Date: Sunday, June 22, 1997 5:03AM
>
>
> Let us market your service/products for you. No autoresponder
> responses,
> just real people, responding to your ad.
>
> We will send your personal ad, directing the receiver to a return e-mail
> address, autoresponder or web site. Only real people, who read your
> message, will be able to respond.
>
> If you receive any complaints, the complainants can not send the true
> header, showing where the message originated, which will protect you
> from losing your ISP. The ISP's require the headers to be sent with the
> message, in order to take action against you. This can not be done as
> we are sending the message with our headers. YOU ARE PROTECTED!!!
> We take all the risk, not YOU.
>
> Our addresses are extracted daily and we have millions. We maintain a
> remove list. This is another added feature. Therefore only those, who
> have not requested their names be removed, will be used. Our remove
> list
> is updated daily by those who use our service. We do ask for anyone's
> name, who responds to your ad and has ask to be removed, so we can keep
> an
> updated list at all times.
>
> $150 for 1,000,000 sent.
>
> Our clients are very satisfied with the service we provide and
> I know you will too. You have probably received some of our mailings.
>
> We only accept checks. Once your check has cleared the bank, we will
> notify you and begin the mailing. We do not write or critique
> ads. You must provide us with your copy ready message. Our mailing
> lists
> are not targeted. If you want us to send to a targeted group, you must
> provide the targeted list. If we have to extract a targeted list, then
> e-mail for prices.
>
> If you are interested, contact us at teamwork at 1stfamily.com
> Type ISP in the subject line.
>
> BRS Services
> 904-282-6987
>
>
Received: from ietf.org by ietf.org id aa15548; 23 Jun 97 18:26 EDT
Received: from ietf.ietf.org by ietf.org id aa15257; 23 Jun 97 18:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
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-negotiate-scenario-00.txt
Date: Mon, 23 Jun 1997 18:18:33 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706231818.aa15257 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 HyperText Transfer Protocol
Working Group of the IETF.
Title : Scenarios for the Delivery of Negotiated Content
using HTTP
Author(s) : Ted Hardie
Filename : draft-ietf-http-negotiate-scenario-00.txt
Pages : 6
Date : 06/16/1997
This document describes various problems which have arisen in attempts to
deliver negotiated content using HTTP and examines several scenarios by
which improvements in delivery might be accomplished.
This document does not discuss how HTTP might be used to negotiate the use
of other protocols to deliver content.
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-negotiate-scenario-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-negotiate-scenario-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-http-negotiate-scenario-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970623171305.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-negotiate-scenario-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-negotiate-scenario-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623171305.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15549; 23 Jun 97 18:26 EDT
Received: from ietf.ietf.org by ietf.org id aa15228; 23 Jun 97 18:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
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-cohen-http-305-306-responses-00.txt
Date: Mon, 23 Jun 1997 18:18:25 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706231818.aa15228 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 HyperText Transfer Protocol
Working Group of the IETF.
Title : HTTP/1.1 305 and 306 Response Codes
Author(s) : J. Cohen
Filename : draft-cohen-http-305-306-responses-00.txt
Pages : 8
Date : 06/16/1997
The HTTP/1.1 RFC specifies a response code '305 Use Proxy' which is
intended to cause a client to retry the request using a specified proxy
server. This functionality is important, but underspecified in the current
spec. The spec does not specify for how long or which URLs the redirect
applies to, or how proxies can deal with or generate similar responses.
This draft proposes a specification for both the 305 response and a new
response, "306 Switch Proxy".
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-cohen-http-305-306-responses-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-cohen-http-305-306-responses-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-cohen-http-305-306-responses-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970623181147.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-cohen-http-305-306-responses-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-cohen-http-305-306-responses-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623181147.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15634; 23 Jun 97 18:26 EDT
Received: from ietf.ietf.org by ietf.org id aa15520; 23 Jun 97 18:24 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: snmpv3 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-snmpv3-acm-00.txt
Date: Mon, 23 Jun 1997 18:24:41 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706231824.aa15520 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 SNMP Version 3 Working Group
of the IETF.
Title : Access Control Model for version 3 of the Simple Network
Management Protocol (SNMPv3)
Author(s) : B. Wijnen, R. Presuhn, K. McCloghrie
Filename : draft-ietf-snmpv3-acm-00.txt
Pages : 32
Date : 06/18/1997
This document describes the Access Control Model (ACM) for SNMP version 3
for use in the SNMP architecture [SNMP-ARCH]. This document defines the
Elements of Procedure for applying access control to management
information. This document also includes a MIB for remotely
monitoring/managing the configuration parameters for this ACM.
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-snmpv3-acm-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-acm-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-snmpv3-acm-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970623182349.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-snmpv3-acm-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snmpv3-acm-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623182349.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15551; 23 Jun 97 18:26 EDT
Received: from ietf.ietf.org by ietf.org id aa15203; 23 Jun 97 18:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-pppext-l2tp-sec-00.txt
Date: Mon, 23 Jun 1997 18:18:14 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706231818.aa15203 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : Layer Two Tunneling Protocol "L2TP" - Security
Extensions for Non-IP networks
Author(s) : Pat Calhoun, W. Mark Townsley
Filename : draft-ietf-pppext-l2tp-sec-00.txt
Pages : 8
Date : 06/16/1997
The L2TP Document defines the base protocol which describes the
method of tunneling PPP data. The spec states that the security mechanism
used over an IP network is to use the IETF's IPSEC protocols.
L2TP was designed in such a way as to be able to run over any
underlying layer (i.e. Frame Relay, ATM, etc.). This document specifies
extensions to the L2TP protocol in order to provide authentication
and integrity of individual packets in a tunneled session over a
non-IP network. It does not intend to provide a mechanism for
encryption of packets.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pppext-l2tp-sec-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-sec-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-l2tp-sec-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970623181644.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-l2tp-sec-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-l2tp-sec-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623181644.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15822; 23 Jun 97 18:29 EDT
Received: from ietf.ietf.org by ietf.org id aa15735; 23 Jun 97 18:27 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: snmpv3 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-snmpv3-v3mpc-model-01.txt
Date: Mon, 23 Jun 1997 18:27:39 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706231827.aa15735 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 SNMP Version 3 Working Group
of the IETF.
Title : Message Processing and Control Model for version 3 of
the Simple Network Management Protocol (snmpv3)
Author(s) : J. Case, D. Harrington, B. Wijnen
Filename : draft-ietf-snmpv3-v3mpc-model-01.txt
Pages : 27
Date : 06/18/1997
This document describes the SNMP version 3 Message Processing and Control
Model for use in the SNMPng architecture [SNMPng]. This model defines the
SNMP version 3 message format, and the procedure for coordinating the
processing of a message in SNMPv3 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-ietf-snmpv3-v3mpc-model-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-v3mpc-model-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-snmpv3-v3mpc-model-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970623182650.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-snmpv3-v3mpc-model-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snmpv3-v3mpc-model-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623182650.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15922; 23 Jun 97 18:31 EDT
Received: from ietf.ietf.org by ietf.org id aa15826; 23 Jun 97 18:29 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: snmpv3 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-snmpv3-usec-01.txt
Date: Mon, 23 Jun 1997 18:29:35 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706231829.aa15826 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 SNMP Version 3 Working Group
of the IETF.
Title : User-based Security Model for version 3 of the Simple
Network Management Protocol (SNMPv3)
Author(s) : U. Blumenthal, B. Wijnen
Filename : draft-ietf-snmpv3-usec-01.txt
Pages : 56
Date : 06/18/1997
This document describes the User-based Security Model (USEC) for SNMP
version 3 for use in the SNMPng architecture [SNMPng-ARCH]. This document
defines the Elements of Procedure for providing SNMP message level
security. This document also includes a MIB for remotely
monitoring/managing the configuration parameters for this Security model.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-snmpv3-usec-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-usec-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-snmpv3-usec-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970623182908.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-snmpv3-usec-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snmpv3-usec-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623182908.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16239; 23 Jun 97 18:41 EDT
Received: from ietf.ietf.org by ietf.org id aa16166; 23 Jun 97 18:39 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: srvloc at corp.home.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-svrloc-discovery-02.txt
Date: Mon, 23 Jun 1997 18:39:24 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706231839.aa16166 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 Service Location Protocol
Working Group of the IETF.
Title : Finding Stuff (How to discover services)
Author(s) : R. Moats, M. Hamilton, P. Leach
Filename : draft-ietf-svrloc-discovery-02.txt
Pages : 8
Date : 06/18/1997
This document proposes a solution to the problem of finding information
about that services are being offered at a particular Internet domain.
Therefore, it is possible for clients, using this approach, to locate
services in a domain with only prior knowledge of the domain name.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-svrloc-discovery-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-discovery-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-svrloc-discovery-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970623183839.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-svrloc-discovery-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-svrloc-discovery-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623183839.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16327; 23 Jun 97 18:43 EDT
Received: from ietf.ietf.org by ietf.org id aa16265; 23 Jun 97 18:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-kalevi-simple-media-access-01.txt
Date: Mon, 23 Jun 1997 18:41:37 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706231841.aa16265 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Simple Integrated Media Access (SIMA)
Author(s) : K. Kilkki
Filename : draft-kalevi-simple-media-access-01.txt
Pages : 24
Date : 06/18/1997
The basic objectives of future Internet are to increase the network
capacity, to offer a practical real-time service, and to develop a feasible
charging scheme. These objectives introduce very strict requirements for
the traffic control system. This paper presents a new simple approach for
traffic management: Simple Integrated Media Access (SIMA) service.
According to the SIMA concept each customer shall define only two issues
before a connection establishment: a nominal bit rate (NBR) and the
selection between real-time and non-real-time service classes. NBR has two
purposes: it forms the basis of charging, and it defines how the network
capacity is divided among different connections during overload situations.
Simplicity means that, on the one hand, the network operator does not
guarantee the continuous availability of network operator does not
guarantee the continuous availability of nominal bit rate, and on the other
hand, the user is allowed to send data with any bit rate independently of
the NBR. However, the bit rate of transmission defines the cell loss
probability in the case of network congestion. In this way a simple, but
effective, self-regulation of traffic can be realized. The strength of SIMA
lies in its wide area of applications. There is no need to build complex
systems with several service classes each appropriate to only
certain applications.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-kalevi-simple-media-access-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-kalevi-simple-media-access-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-kalevi-simple-media-access-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970623184027.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-kalevi-simple-media-access-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-kalevi-simple-media-access-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623184027.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16463; 23 Jun 97 18:47 EDT
Received: from ietf.ietf.org by ietf.org id aa16395; 23 Jun 97 18:45 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: snmpv3 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-snmpv3-next-gen-arch-02.txt
Date: Mon, 23 Jun 1997 18:45:14 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706231845.aa16395 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 SNMP Version 3 Working Group
of the IETF.
Title : An Architecture for Describing
Internet Management Frameworks
Author(s) : D. Harrington, B. Wijnen
Filename : draft-ietf-snmpv3-next-gen-arch-02.txt
Pages : 40
Date : 06/18/1997
This document describes an architecture for describing Internet Management
Frameworks. The architecture is designed to be modular to allow the
evolution of the protocol over time. The major portions of the architecture
are a messaging engine containing a message processing and control
subsystem and a security subsystem, plus a data processing engine, called a
context engine, which contains an access control subsystem, a MIB access
subsystem, and possibly multiple orangelets which provide specific
functional processing of network management data.
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-snmpv3-next-gen-arch-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-next-gen-arch-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-snmpv3-next-gen-arch-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970623184432.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-snmpv3-next-gen-arch-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snmpv3-next-gen-arch-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623184432.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16713; 23 Jun 97 18:52 EDT
Received: from ietf.ietf.org by ietf.org id aa16527; 23 Jun 97 18:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-auth-01.txt
Date: Mon, 23 Jun 1997 18:49:45 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706231849.aa16527 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Roaming Operations Working
Group of the IETF.
Title : Guidelines for the Secure Operation of
RADIUS Proxies in Roaming
Author(s) : B. Aboba, G. Zorn
Filename : draft-ietf-roamops-auth-01.txt
Pages : 11
Date : 06/18/1997
Today, RADIUS proxy chaining is widely deployed for the purposes of
providing roaming services. This document provides guidelines for the
secure operation of RADIUS proxies within roaming systems.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-auth-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-auth-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-auth-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970623184619.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-auth-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-auth-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623184619.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01252; 23 Jun 97 20:22 EDT
Received: from zephyr.isi.edu by ietf.org id aa01003; 23 Jun 97 20:12 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
id <AA04500>; Mon, 23 Jun 1997 17:08:14 -0700
Message-Id: <199706240008.AA04500 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2168 on Resolution of URIs Using the DNS
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 23 Jun 97 17:08:14 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 2168:
Title: Resolution of Uniform Resource Identifiers
using the Domain Name System
Author: R. Danie1, M. Mealling
Date: June 1997
Mailbox: rdaniel at lanl.gov, michaelm at internic.net
Pages: 20
Characters: 46528
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2168.txt
The requirements document for URN resolution systems defines the
concept of a "resolver discovery service". This document describes the
first, experimental, RDS. It is implemented by a new DNS Resource
Record, NAPTR (Naming Authority PoinTeR), that provides rules for
mapping parts of URIs to domain names. This document is a product of
the Uniform Resource Names Working Group of the IETF.
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
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 IETF.ORG. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970623170312.RFC at ISI.EDU>
SEND /rfc/rfc2168.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2168.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970623170312.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01250; 23 Jun 97 20:22 EDT
Received: from zephyr.isi.edu by ietf.org id aa01017; 23 Jun 97 20:12 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26)
id <AA04539>; Mon, 23 Jun 1997 17:08:22 -0700
Message-Id: <199706240008.AA04539 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2168 on Resolution of URIs Using the DNS
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 23 Jun 97 17:08:22 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 2168:
Title: Resolution of Uniform Resource Identifiers
using the Domain Name System
Author: R. Danie1, M. Mealling
Date: June 1997
Mailbox: rdaniel at lanl.gov, michaelm at internic.net
Pages: 20
Characters: 46528
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2168.txt
The requirements document for URN resolution systems defines the
concept of a "resolver discovery service". This document describes the
first, experimental, RDS. It is implemented by a new DNS Resource
Record, NAPTR (Naming Authority PoinTeR), that provides rules for
mapping parts of URIs to domain names. This document is a product of
the Uniform Resource Names Working Group of the IETF.
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
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 IETF.ORG. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970623170312.RFC at ISI.EDU>
SEND /rfc/rfc2168.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2168.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970623170312.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11975; 24 Jun 97 2:03 EDT
Received: from gw.home.vix.com by ietf.org id aa11849; 24 Jun 97 1:56 EDT
Received: from wisdom.home.vix.com (wisdom.home.vix.com [192.5.5.7])
by gw.home.vix.com (8.8.6/) via ESMTP id WAA02609
for <ietf at ietf.org>; Mon, 23 Jun 1997 22:52:05 -0700 (PDT)
env-from (vixie at vix.com)
Received: by wisdom.home.vix.com; id WAA25384; Mon, 23 Jun 1997 22:52:05 -0700
Message-Id: <199706240552.WAA25384 at wisdom.home.vix.com>
X-Authentication-Warning: wisdom.home.vix.com: localhost [127.0.0.1] didn't use HELO protocol
To: ietf at ietf.org
Subject: BIND 8.1.1 and BIND 4.9.6 announcement
Date: Mon, 23 Jun 1997 22:52:05 -0700
Sender:ietf-request at ietf.org
From: Paul A Vixie <paul at vix.com>
Source-Info: From (or Sender) name not authenticated.
-----BEGIN PGP SIGNED MESSAGE-----
Announcing BIND 8.1.1. If you are running BIND 8.1 you want to upgrade.
Announcing BIND 4.9.6. If you are still running BIND-4 rather than BIND-8,
you need the security patches contained herein. But, you should really just
run BIND-8. (See below for motivation.)
BIND is brought to you by the Internet Software Consortium, which provides
publically available references of key portions of Internet infrastructure.
Our 1997 sponsors include Usenix and Network Solutions. See
<URL:http://www.isc.org/isc/> for more details.
The most recent security fix is for the trouble reported a while back on
various mailing lists and recently demonstrated with a publically visible
CGI script used to corrupt caches.
Note that there is nothing we can really do about DNS Security until and
unless either the SIG/KEY/NXT stuff, and possibly the TSIG stuff, are
standardized and implemented. However, in the meanwhile, we can increase
the DNS load on the Internet's backbone by about 40% by not caching anything
which might be suspicious if only we'd be paranoid enough.
Looks like from now on we're paranoid enough.
BIND 8.1.1's changes from BIND 8.1-REL include:
-> Improved security.
-> libbind.a and .h files are installed under /usr/local/bind instead
of under /usr/local.
-> Bug fixes.
-> Additional recipients of DNS Change Notification messages may
be specified with the also-notify zone option.
-> Added periodic interface scanning.
-> New configuration options: dump-file, statistics-file,
clean-interval, interface-interval, and statistics-interval.
-> Ports to OpenBSD 2.1, SCO UnixWare 2.1.2, AIX 4.
-> Etc, etc. (You should the CHANGES file now.)
BIND 4.9.6's changes from BIND 4.9.5-P1 include:
-> Improved security.
-> Core leak plugged.
-> Descriptor leak plugged.
-> Named-xfer temporary files removed more often.
-> Motorola 88K port included.
-> Etc, etc. (You should the CHANGES file now.)
BIND 8's features over BIND 4 are too numerous to mention here, but they
include:
-> DNS Dynamic Updates (RFC 2136).
-> DNS Change Notification (RFC 1996).
-> Completely new configuration syntax (and HTML docs for same).
-> Flexible, categorized logging system (blackhole lame delegations!).
-> IP-address-based access control for queries, zone transfers, and
updates that may be specified on a zone-by-zone basis.
-> More efficient zone transfers (no fork() on outbound!).
-> Improved performance for servers with thousands of zones.
-> get*by*() functions can now use Sun NIS if desired/available.
-> Many bug fixes, including patches for all known security holes.
Bob and I would like to thank Viraj Bais of Intel for his reference
implementation of Dynamic DNS, which 8.1's dynamic DNS is built upon. We'd
also like to thank everyone who has sent us bug reports, patches, or
operating system ports.
The release files are:
BIND 8.1.1:
ftp://ftp.isc.org/isc/bind/src/8.1.1/bind-src.tar.gz source code
ftp://ftp.isc.org/isc/bind/src/8.1.1/bind-src.tar.gz.asc PGP sig
ftp://ftp.isc.org/isc/bind/src/8.1.1/bind-doc.tar.gz documentation
ftp://ftp.isc.org/isc/bind/src/8.1.1/bind-doc.tar.gz.asc PGP sig
ftp://ftp.isc.org/isc/bind/src/8.1.1/bind-contrib.tar.gz contributions
ftp://ftp.isc.org/isc/bind/src/8.1.1/bind-contrib.tar.gz.asc PGP sig
BIND 4.9.6:
ftp://ftp.isc.org/isc/bind/src/4.9.6/bind-4.9.6-REL.tar.gz whole thing
ftp://ftp.isc.org/isc/bind/src/4.9.6/bind-4.9.6-REL.tar.gz.asc PGP sig
The ".asc" files are PGP signatures for the kits, signed with the
<pgpkey at isc.org> key. This key has been submitted to the MIT key ring with
a lot of well known signatures on it. It can also be found at
<URL:http://www.isc.org/isc/> along with a lot of other ISC related
material that we hope you'll glance through.
There is a newish mailing list: <bind-bugs at isc.org>. Submit bug reports to
it so that both Bob Halley and Paul Vixie will see them, and they will be
archived. This is not a mailing list in the traditional sense -- there are
no external subscribers.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBM69gAHcdkq6JcsfBAQEhQAQAx0BI0xPqEX0G8BmQUNlTsgXzHt8lrvIS
9AvgX0ADzT5BPc1nKHPYEeeG995ck4I7KiRCTaKldqJCptgrK48t8WVWQVarVFD7
W3HDqO9QTENbj4k/2ojvK9s9vNyoPKNgAAg9fWMUCxKm16N4LCfNpmCFJGMfk4ri
yvgV8YBCrS4=
=fn9f
-----END PGP SIGNATURE-----
Received: from ietf.org by ietf.org id aa07609; 24 Jun 97 10:42 EDT
Received: from ietf.ietf.org by ietf.org id aa06744; 24 Jun 97 10:23 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-newman-sasl-anon-00.txt
Date: Tue, 24 Jun 1997 10:23:48 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706241023.aa06744 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Anonymous SASL Mechanism
Author(s) : C. Newman
Filename : draft-newman-sasl-anon-00.txt
Pages : 5
Date : 06/23/1997
It is common practice on the Internet to permit anonymous access to various
services. Traditionally, this has been done within the context of a plain
text password mechanism using "anonymous" as the user name and trace
information, such as an email address, as the password. As SASL [SASL]
provides a framework for authentication mechanisms, a formalized anonymous
mechanism is simple to add.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-newman-sasl-anon-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-newman-sasl-anon-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-newman-sasl-anon-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970623185813.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-newman-sasl-anon-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-newman-sasl-anon-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623185813.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07599; 24 Jun 97 10:42 EDT
Received: from ietf.ietf.org by ietf.org id aa06853; 24 Jun 97 10:24 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: issll at mercury.lcs.mit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-issll-802-01.txt
Date: Tue, 24 Jun 1997 10:23:57 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706241024.aa06853 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integrated Services over
Specific Link Layers Working Group of the IETF.
Title : Integrated Services over IEEE 802.1D/802.1p Networks
Author(s) : M. Seaman, A. Smith, E. Crawley
Filename : draft-ietf-issll-802-01.txt
Pages : 32
Date : 06/23/1997
This document describes the support of IETF Integrated Services over LANs
built from IEEE 802 network segments which may be interconnected by draft
standard IEEE P802.1p switches.
It describes the practical capabilities and limitations of this technology
for supporting Controlled Load [8] and Guaranteed Service [9] using the
inherent capabilities of the relevant 802 technologies [5],[6] etc. and the
proposed 802.1p queuing features in switches. IEEE P802.1p [2] is a
superset of the existing IEEE 802.1D bridging specification. This document
provides a functional model for the layer 3 to layer 2 and user-to-network
dialogue which supports admission control and defines requirements for
interoperability between switches. The special case of such networks where
the sender and receiver are located on the same segment is also discussed.
This scheme expands on the ISSLL over 802 LANs framework described in [7].
It makes reference to an admission control signaling protocol developed by
the ISSLL WG which is known as the "Subnet Bandwidth Manager". This is an
extension to the IETF's RSVP protocol [4] and is described in a separate
document [10].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-issll-802-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-issll-802-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-issll-802-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970623193213.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-issll-802-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-issll-802-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623193213.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07585; 24 Jun 97 10:42 EDT
Received: from ietf.ietf.org by ietf.org id aa06764; 24 Jun 97 10:23 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
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-mars-mib-01.txt
Date: Tue, 24 Jun 1997 10:23:46 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706241023.aa06764 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internetworking Over NBMA
Working Group of the IETF.
Title : Definitions of Managed Objects for Multicast over UNI
3.0/3.1 based ATM Networks
Author(s) : C. Chung, M. Greene
Filename : draft-ietf-ion-mars-mib-01.txt
Pages : 56
Date : 06/23/1997
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects for IP hosts and
routers that use a Multicast Address Resolution Server (MARS) to support IP
multicast over ATM, as described in "Support for Multicast over UNI 3.0/3.1
based ATM Networks" [1].
This memo specifies a MIB module in a manner that is both compliant to the
SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ion-mars-mib-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-mars-mib-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ion-mars-mib-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970623185529.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-mars-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-mars-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623185529.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07600; 24 Jun 97 10:42 EDT
Received: from ietf.ietf.org by ietf.org id aa06769; 24 Jun 97 10:23 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-acap+ at andrew.cmu.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-acap-langtag-00.txt
Date: Tue, 24 Jun 1997 10:23:50 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706241023.aa06769 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 Application Configuration
Access Protocol Working Group of the IETF.
Title : Two Alternative Proposals for Language Taging in ACAP
Author(s) : M. Duerst
Filename : draft-ietf-acap-langtag-00.txt
Pages : 13
Date : 06/23/1997
For various computing applications, it is helpful to know the language of
the text being processed. This can be the case even if otherwise only pure
character sequences (so-called plain text) are handled. From several
sides, the need for such a scheme for ACAP has been claimed.
One specific scheme, called MLSF, has also been proposed, see
draft-ietf-acap-mlsf-01.txt for details. This document proposes two
alternatives to MLSF. One alternative is using text/enriched-like markup.
The second alternative is using a special tag-introduction character.
Advantages and disadvantages of the various proposals are discussed. Some
general comments about the topic of language tagging are given in the
introduction.
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-acap-langtag-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-acap-langtag-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-acap-langtag-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970623190356.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-acap-langtag-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-acap-langtag-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623190356.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07601; 24 Jun 97 10:42 EDT
Received: from ietf.ietf.org by ietf.org id aa06804; 24 Jun 97 10:23 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-tbnadn-sec-label-00.txt
Date: Tue, 24 Jun 1997 10:23:55 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706241023.aa06804 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Internet Security Label (ISL)
Author(s) : T. Bartee, N. Alvarez, C. Nunley
Filename : draft-tbnadn-sec-label-00.txt
Pages : 24
Date : 06/23/1997
This document describes the Internet Security Label (ISL). ISL provides a
mechanism for encoding security (sensitivity) parameters. The ISL is
intended to be a layer-independent security mechanism. It can be used with
all current versions of the Internet Protocol (IP), including IPv4 and IPv6
as well as the IP Security Protocols (IPSEC), the encapsulating Security
Payload (ESP) and the Authentication Header (AH). Other protocols which use
a security label can also use the ISL encoding standard including IPX.
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-tbnadn-sec-label-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-tbnadn-sec-label-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-tbnadn-sec-label-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970623191549.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-tbnadn-sec-label-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-tbnadn-sec-label-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623191549.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07598; 24 Jun 97 10:42 EDT
Received: from ietf.ietf.org by ietf.org id aa06873; 24 Jun 97 10:24 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-pkix at tandem.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-pkix-ipki3cmp-02.txt
Date: Tue, 24 Jun 1997 10:24:06 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706241024.aa06873 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 Public-Key Infrastructure
(X.509) Working Group of the IETF.
Title : Internet Public Key Infrastructure Part III:
Certificate Management Protocols
Author(s) : C. Adams, S. Farrell
Filename : draft-ietf-pkix-ipki3cmp-02.txt
Pages : 68
Date : 06/23/1997
This is a draft of the Internet Public Key Infrastructure (X.509)
Certificate Management Protocols. Protocol messages are defined for all
relevant aspects of certificate creation and management.
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-pkix-ipki3cmp-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki3cmp-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pkix-ipki3cmp-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970623194635.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ipki3cmp-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pkix-ipki3cmp-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623194635.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07580; 24 Jun 97 10:42 EDT
Received: from ietf.ietf.org by ietf.org id aa06838; 24 Jun 97 10:24 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-newman-protocol-design-00.txt
Date: Tue, 24 Jun 1997 10:23:59 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706241024.aa06838 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Application Protocol Design Principles
Author(s) : C. Newman
Filename : draft-newman-protocol-design-00.txt
Pages : 6
Date : 06/23/1997
There are a number of design principles which come into play over and over
again when designing application protocols. Many of these are entrenched
in IETF lore and spread by word of mouth. Most have been learned the hard
way many times.
This is an attempt to codify some of these principles so they can be
referenced rather than spread by word of mouth. The author has not
invented any of these ideas and while the exercise of finding the
originator of the ideas would be interesting, it is not deemed necessary
for this project.
Many of these principles have a much wider scope than
application protocol design. However, the author's primary experience is
with application protocols and examples provided usually involve
application protocols or elements.
[Disclaimer: this is a preliminary draft. Some of the case studies and
exceptions need tuning. Suggestions welcome.]
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-newman-protocol-design-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-newman-protocol-design-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-newman-protocol-design-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970623194237.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-newman-protocol-design-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-newman-protocol-design-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623194237.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07959; 24 Jun 97 10:50 EDT
Received: from ietf.ietf.org by ietf.org id aa07826; 24 Jun 97 10:47 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-newman-sasl-plaintrans-02.txt
Date: Tue, 24 Jun 1997 10:47:29 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706241047.aa07826 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Plaintext Password SASL Mechanism and Transition Codes
Author(s) : C. Newman
Filename : draft-newman-sasl-plaintrans-02.txt
Pages : 7
Date : 06/23/1997
While plaintext passwords have very poor security characteristics by
themselves, there are a number of contexts where they are useful or
necessary. This defines a plaintext password mechanism for SASL [SASL]
which is intended to be used in combination with an external encryption
layer, as a transition mechanism from a legacy authentication database, or
to use (insecurely) a legacy authentication database which can not
practically be replaced.
In hopes of promoting the future elimination of unencrypted plaintext
passwords, this defines error codes for use with POP3 and IMAP4: one to
indiciate the need for a transition to a stronger mechanism, a second to
indicate that plaintext passwords are no longer accepted by a given
service, and a third to indicate that plaintext passwords are only accepted
by a given service in combination with an external strong encryption
mechanism. Any protocol offering the PLAIN mechanism should also support
these error codes.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-newman-sasl-plaintrans-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-newman-sasl-plaintrans-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-newman-sasl-plaintrans-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970623183624.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-newman-sasl-plaintrans-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-newman-sasl-plaintrans-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623183624.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08376; 24 Jun 97 11:07 EDT
Received: from ietf.ietf.org by ietf.org id aa08173; 24 Jun 97 11:03 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
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-state-man-mec-02.txt, .ps
Date: Tue, 24 Jun 1997 11:03:08 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706241103.aa08173 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 : HTTP State Management Mechanism (Rev1)
Author(s) : D. Kristol, L. Montulli
Filename : draft-ietf-http-state-man-mec-02.txt, .ps
Pages : 22
Date : 06/23/1997
This document specifies a way to create a stateful session with HTTP
requests and responses. It describes two new headers, Cookie and
Set-Cookie2, which carry state information between participating origin
servers and user agents. The method described here differs from Netscape's
Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use
Netscape's method. (See the HISTORICAL section.)
This document reflects implementation experience with RFC 2109
and obsoletes it.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-http-state-man-mec-02.txt".
Or
"get draft-ietf-http-state-man-mec-02.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-state-man-mec-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-http-state-man-mec-02.txt".
Or
"FILE /internet-drafts/draft-ietf-http-state-man-mec-02.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.
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: <19970623190800.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-state-man-mec-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-state-man-mec-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970623190800.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08368; 24 Jun 97 11:07 EDT
Received: from ietf.ietf.org by ietf.org id aa08276; 24 Jun 97 11:04 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-greenblatt-defema-01.txt
Date: Tue, 24 Jun 1997 11:04:52 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9706241104.aa08276 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Directory Entries From Email Address
Author(s) : B. Greenblatt
Filename : draft-greenblatt-defema-01.txt
Pages : 3
Date : 06/16/1997
This draft describes various means for finding a user's directory entry in
a LDAP directory presuming that the user's electronic mail address is
known. This draft does not presume any specific DIT structure or schema
modifications.
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-greenblatt-defema-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-greenblatt-defema-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-greenblatt-defema-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970624110353.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-greenblatt-defema-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-greenblatt-defema-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970624110353.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09100; 24 Jun 97 11:44 EDT
Received: from muenster.westfalen.de by ietf.org id aa08902; 24 Jun 97 11:35 EDT
Received: from khms.westfalen.de by muenster.westfalen.de
via rsmtp with bsmtp
id <m0wgXYh-000DoGC at muenster.westfalen.de>
for <ietf at ietf.org>; Tue, 24 Jun 1997 17:31:07 +0200 (CEST)
(Smail-3.2 1996-Jul-4 #1 built 1996-Nov-13)
Received: by khms.westfalen.de (CrossPoint v3.11 R/C435);
24 Jun 1997 17:00:04 +0200
Date: 24 Jun 1997 09:36:00 +0200
Sender:ietf-request at ietf.org
From: Kai Henningsen <kai at khms.westfalen.de>
To: ietf at ietf.org
Message-ID: <6ZS0Xj-jcsB at khms.westfalen.de>
In-Reply-To: <Pine.SOL.3.96.970623122056.5804A-100000 at pax.cavebear.com>
Subject: Re: FW: ISP!
X-Mailer: CrossPoint v3.11 R/C435
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Organization: Organisation? Me?! Are you kidding?
References: <c=US%a=_%p=hmhs%l=HMHS/TEXAS/0007486E at svarlexc01.hmhs.com> <Pine.SOL.3.96.970623122056.5804A-100000 at pax.cavebear.com>
X-No-Junk-Mail: I do not want to get *any* junk mail.
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Source-Info: From (or Sender) name not authenticated.
karl at cavebear.com (Karl Auerbach) wrote on 23.06.97 in <Pine.SOL.3.96.970623122056.5804A-100000 at pax.cavebear.com>:
> Beware, however, that the spammers organization has made less than veiled
> threats to invoke various forms of "cyberterrorists" (my term) from
> various countries (especially Germany) on those who they consider
> non-friendly.
Well, I seem to have made it onto their hate list, and they sure don't
send _from_ Germany. I don't think they'd survive that long if they tried;
but of course, I could be wrong.
MfG Kai
Received: from ietf.org by ietf.org id aa09097; 24 Jun 97 11:44 EDT
Received: from access.netaxs.com by ietf.org id aa08817; 24 Jun 97 11:32 EDT
Received: from unix1.netaxs.com (mail at unix1.netaxs.com [207.8.186.3])
by access.netaxs.com (8.8.5/8.8.5) with ESMTP id LAA24933
for <ietf at ietf.org>; Tue, 24 Jun 1997 11:27:56 -0400 (EDT)
Received: (from cook at localhost)
by unix1.netaxs.com (8.8.5/8.8.4)
id LAA29527; Tue, 24 Jun 1997 11:27:55 -0400 (EDT)
Date: Tue, 24 Jun 1997 11:27:55 -0400 (EDT)
Sender:ietf-request at ietf.org
From: Gordon Cook <cook at netaxs.com>
To: ietf at ietf.org
Subject: The American Registry for Internet Numbers has just been approved
Message-ID: <Pine.SUN.3.95.970624112348.28870H-100000 at unix1.netaxs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: QUOTED-PRINTABLE
Source-Info: From (or Sender) name not authenticated.
[I believe the formation of ARIN is very important to the stability of the
Internet and am therefore taking the liberty of letting the IETF community
know what has just happened.]
June 24: The National Science Foundation has just announced the formation
of ARIN, (The American Registry for Internet Numbers). NSF has approved a
Network Solutions plan to set up the independent IP registry. All
necessary documents are signed and in place. Steps to establish ARIN begin
immediately. The enabling breakthrough came in negotiations between the
parties last week in Washington.
From=20the July - August COOK Report on Internet - published today.
Administration Approves Formation of ARIN, pp. 1-10
In an eleventh hour decision last week, the Clinton Administration dropped
its opposition to an American Registry for Internet Numbers. Ira Magaziner
finally grasped what was at stake and, to his credit, acted forcefully to
end foot dragging by other agencies. We applaud these events. For the
approval for NSF to set up ARIN actually takes the first important and
coherent step towards the Administration's announced goal of industry
driven self- regulation.
Nevertheless, the road to last week's decision was marked by a remarkable
amount of bungling and lack of both coordination and leadership among
federal agencies that, in the feelings of some, were more interested in
protecting their turf and in not making "wrong" decisions than in really
trying to understand the key reasons behind the crisis in Internet
governance. Several issues compounded the problem. First, OMB, because of
its role in coordinating implementation of the Federal Administrative
Procedures Act, took a major role in deciding what should be done.
Unfortunately the players at OMB had no understanding of the complicated
historical, political and legal linkages that they were dealing with when,
having been called on to fix Domain Name Service, they decided also to
meddle in IP numbers.
Second, while the policy makers felt there were issues of control over
business critical elements of DNS as well as uncertainties about the role
of the ITU and viability of the IAHC process, the Inter Agency Task Force
set up to deal with the issue had no leadership worthy of the name. Many
of the stake holders had no grasp of the technical complexity and legal
linkages between what undoubtedly first appeared to them as nothing more
complicated than intellectual property aspects of obtaining business
addresses in Cyberspace. One person directly involved expressed dismay to
us at the enormous gulf he saw between the concerns of the network
engineers and the non technical policy wonks - something that he simply
did not understand but intuited to be serious.
Finally, in such a context, the only way to avoid disaster, was for those
interested to lobby the top policy makers such as Magaziner and do
whatever it took to educate them. We report with considerable relief that
this seems to be what was finally accomplished last week. What we have
seen however is only Act One. There is still much that remains to be
decided about DNS policy. Some court cases are underway that will likely
force rapid decisions. Some are also asserting that the "old boys network"
of Internet governance is dead and that the commercial Internet industry
must now throw out the consensual processes that have been the foundation
of the Internet's growth and prosperity. These people we have little
respect for. Therefore, in order to spread awareness of what has happened,
we present a detailed summary of the behind the scenes maneuvering of the
past two months.
In April ARIN was back on track and headed for a September 1 opening,
when, suddenly at the beginning of May, we received word that ARIN was
once again on hold. Why? Because OMB had decided to fix the problems of
IP. The only problem was that the underlying problems, which are
technical, are not administratively "fixable=D3, and the people sitting
around the Inter Agency DNS Task Force table either didn't know it or
would not admit it. After sending scathing private mail to an
administration official, we received a reply on May 11 that told us worlds
about the problem. "As far as I know -- the only outstanding objection to
ARIN is whether they are dealing with number portability.? Certainly --
number portability is critical in the telephony context to promoting
competition - so people are asking -- why not portability for Internet?
If you have any recommendations for people on the technical side - I'd
appreciate it."
We passed this data along to the appropriate technical leadership of the
net, went to Russia and waited for more news. When it came it was that a
succession of technical folk had done the educating called for but that
amazingly ARIN had been thrown a new curve. The feds were now insisting it
be announced in the Federal Registry before it was formed. We were told
that this new delay would kill ARIN, and that worse, it was doing nothing
to solve the authority problems of the IANA.
On June 2 Ken Cukier published an extremely important article in
Communications Week International. It detailed the Dublin meeting of RIPE
the European Registry that had occurred a few days earlier. There it was
announced that both RIPE and APNIC had made monetary contributions to take
up the slack in IANA funding in view of ARPA's non renewal of the contract
with ISI that had paid for many of Jon Postel's functions. For the more
knowledgeable here was a clear implication that, if the US government
didn't do something to stabilize IANA's problems, Postel could simply move
this critical piece of Internet governance outside of the US. We sent the
article to our electronic subscribers as an "extra" and later heard that
the contents had found their way to the June 3rd meeting of the
Interagency DNS Task Force where they had had a significant impact in
raising the level of consciousness of what was at stake.
In the meantime, on the way home, a visit to London (June 9 -13) enabled
us to discuss matters with Tony Rutkowski, some key US regulators, and the
CIX President and Executive Director. These meetings gave us a more
balanced view of the position of the "other side". The CIX in particular
indicated a feeling that ARIN was not urgent and that it was time for
commercial providers working through a US Government "process" to reshape
the way the net was run. Discussion with others after our return from
Russia and London has left us viewing the CIX position with considerable
dismay.
With ARIN on hold, needed fundamental changes in IP policy could not be
made. But with dues of $1000 a year, we'd estimate that 4 out of every 5
ISPs in the ARIN service area could afford to join. Since the member ISPs
will elect the ARIN Policy Council, it seems to us that on sheer numbers
alone, ARIN can be an effective mechanism against unwarranted industry
consolidation.
We have had serious doubts about the Clinton Administration's Internet
policy. In this instance the Administration did the "right thing." We hope
that it will continue to do so on heels of challenges that will follow.
USIPA Lawyer Fails to Understand Needs of ISPs, pp. 11 - 13
On April 28, in some critical discussions on the NAIPR mail list, USIPA
lawyer Rudolph Geist painted ARIN as device hatched by a monopoly in order
to become another monopoly and perpetuate the interests of Network
Solutions and the big service providers. To the response of Philip Nesser
"I don't believe that the process should be completely open to the public
(the finances yes, but not technical applications) because the information
requested may be considered proprietary by many organizations;"
Geist replied: "It is highly suspicious to maintain that technical
information (or any information for that matter) regarding the allocation
of IP address blocks, a finite public resource (like telephone numbers or
radio spectrum), should be held proprietary by a monopoly outgrowth
(ARIN) of another monopoly (Internic)." It developed that at least in one
instance his way of trying to get an address block for his clients was by
threatening to sue InterNic or force it to break the procedures set forth
in RFC 2050. We believe that neither Mr. Geist nor his organization
deserves respect.
Seven New gTLDs Make No Business Sense, p. 14
A short cogent critique by Vanderbilt Professor Donna Hoffman
UUNET and Sprint Charging for Peering, pp. 15 - 23
At the very end of April, in an explosion that rocked the Well and its ISP
Whole Earth Networks (WeNet), David Holub, WeNet's founder refused an
order from Well owner Bruce Katz to capitulate to UUNET's demand for paid
peering. Holub was fired for taking what we view as a courageous stand
against UUNET's insidious policy (since modified) of insisting that anyone
who wished to even talk about remaining a UUNET peer would have to sign a
non disclosure agreement that would presumably keep the fact that paid
peering was under discussion and the price paid for peering a secret.
UUNET actually had bought about three months of silence with this policy
before Holub's courageous action blew the whistle.=20
In the meantime Sprint began a policy by which its peers would have to pay
in declining amounts, according to the number of exchange points where
they conducted peering. Sprint's prices represent an average cost increase
of $200,000 a year for each peer. If we look at the big five privately
peered providers, we can see that, should all of them start doing what
Sprint and UUNET have done, the average increase in operating expenses for
the peers would be a million dollars a year per backbone. While Sprint and
UUNET offered technical justifications for their charges, the cost benefit
assessment of who should settle with whom in a connectionless network is
still no more clear than it has been in the many many discussions of these
kinds of issues that have cropped up on NANOG and elsewhere over the last
couple of years.
What does seem obvious is that there may be strong anti-competitive
elements lurking in these new policies. Roughly two years ago
the big five established criteria for free peering. Since then between 15
and 20 national high speed backbones have appeared that meet the criteria
- far more than many ever imagined possible. Now that this has happened,
at least some of the big five are changing the rules in such a way as to
put a financial squeeze on their own would be competitors. We present our
own analysis of these events and a summary of mail list discussion from
early May through mid June.
Holub's Model of Open Peering Open Interconnect Internet, pp. 24 - 26
David Holub went to the California PUC and managed to have WeNet declared
a common carrier. In a NANOG discussion with Kent England, he presents his
strategy for open peering.
Choosing an Upstream Provider and the Cost Equation for Dial Up Service,
pp. 27-29, 48
On inet-access Sean Donelan provides valuable advice on the variable to
consider when shopping for backbone service. Also welcome news is ANS's
recent serious entry into providing backbone service for ISPs. In a second
discussion, several ISPs respond to Avi Freedman's query on the costs of
providing their dial up service.
NSF Inspector General's Defunct Plan to Tax Domain Names, pp. 30 -35
This absurd plan was officially rejected on April 17. We publish our
analysis of it and the plan itself in full as a monument to the kind of
thinking that real policy makers should in future avoid.
State of Russian Internet, p. 36
Brief reflections on internet developments in Russia.
Book Reviews, pp. 37 - 40
Reviews of recent O'Reilly books on Java and the Web by Russian
programmers in St Petersburg.
K - 12 Technology Debate, pp. 41 - 46
Part 2 of a debate between Ferdi Serim and Jeff Michka. Part 1 appeared
in the Feb 97 COOK Report.
************************************************************************
The COOK Report on Internet http://cookreport.com/
Received: from ietf.org by ietf.org id aa09544; 24 Jun 97 12:03 EDT
Received: from xap.xyplex.com by ietf.org id aa09419; 24 Jun 97 11:59 EDT
Received: from nln.xyplex.com (nln.xyplex.com [140.179.146.21]) by xyplex.com (8.8.5/8.7.3) with SMTP id LAA23881 for <ietf at ietf.org>; Tue, 24 Jun 1997 11:54:28 -0400 (EDT)
Received: by nln.xyplex.com (4.1/SMI-4.1)
id AA06625; Tue, 24 Jun 97 11:55:36 EDT
Date: Tue, 24 Jun 97 11:55:36 EDT
Sender:ietf-request at ietf.org
From: Nancy Nichols <nancy at xyplex.com>
Message-Id: <9706241555.AA06625 at nln.xyplex.com>
To: ietf at ietf.org
Subject: question on RFC1812 section 5.3.5.2 - directed broadcasts
Source-Info: From (or Sender) name not authenticated.
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.
