[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
I also contact Sheraton Internation reservation line (US) and they said
the IETF was not available in their computers. If it is not available
there, I believe the only way to get the special rate right now is
to call direct the Sheraton Hotel in Munchen.
Claude
Received: from ietf.org by ietf.org id aa22112; 15 Apr 97 21:16 EDT
Received: from email.archlab.tuwien.ac.at by ietf.org id aa22008;
15 Apr 97 21:15 EDT
Received: by email.archlab.tuwien.ac.at (950413.SGI.8.6.12/940406.SGI.AUTO)
id DAA06663; Wed, 16 Apr 1997 03:12:49 +0200
Date: Wed, 16 Apr 1997 03:12:48 +0200 (MDT)
Sender:ietf-request at ietf.org
From: Sascha Ignjatovic <signato at email.archlab.tuwien.ac.at>
To: ietf at ietf.org
Subject: munich
Message-ID: <Pine.SGI.3.91.970416030353.6591A-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 nice if the gays from munich can be helpful to the ietf geeks
and find for them sam good sleaping facilitys for reasonable money
or at least give them ideas how to find it by them self
to pay so much money for sleaping its a sin :-)
you can sleep in a youth host for 40 dm per night
of course with sam other ietf geeks in the same room but exactly this can
be very extatic :-)
sasha
Received: from ietf.org by ietf.org id aa11259; 16 Apr 97 5:05 EDT
Received: from mail2.zocalo.net by ietf.org id aa10639; 16 Apr 97 4:50 EDT
Received: from zocalo.net (zocalo.net [157.22.1.7]) by mail.zocalo.net (8.7.5/8.7.3) with ESMTP id BAA04689 for <ietf at ietf.org>; Wed, 16 Apr 1997 01:56:18 -0700 (PDT)
Received: (from woody at localhost) by zocalo.net (8.7.5/8.7.3) id AAA10002 for ietf at ietf.org; Wed, 16 Apr 1997 00:09:48 -0700 (PDT)
Date: Wed, 16 Apr 1997 00:09:48 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Bill Woodcock <woody at zocalo.net>
Message-Id: <199704160709.AAA10002 at zocalo.net>
To: ietf at ietf.org
Subject: Re: Re[2]: Hotel space in Munich
Source-Info: From (or Sender) name not authenticated.
Oh, come on... Did any of you whiners actually bother to call the
hotel? They've got plenty of rooms left, and they'll happily give
them to you at the stated rate of 185 DM/night, which as has been
pointed out, is only $110/night. You'd be lucky to get anything
better than a Travelodge or Best Western at that price in the U.S.
-Bill
______________________________________________________________________________
bill woodcock woody at zocalo.net woody at nowhere.loopback.edu user at host.domain.com
Received: from ietf.org by ietf.org id aa13161; 16 Apr 97 6:23 EDT
Received: from ncc.ripe.net by ietf.org id aa13073; 16 Apr 97 6:20 EDT
Received: from x0.ripe.net by ncc.ripe.net with SMTP
id AA22492 (5.65a/NCC-2.41); Wed, 16 Apr 1997 12:17:13 +0200
Received: from x0.ripe.net (localhost.ripe.net [127.0.0.1]) by x0.ripe.net (8.8.5/8.7.3) with ESMTP id MAA02294; Wed, 16 Apr 1997 12:17:12 +0200 (MET DST)
Message-Id: <199704161017.MAA02294 at x0.ripe.net>
To: Bill Flanigan <flanigab at ncr.disa.mil>
Cc: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Geert Jan de Groot <GeertJan.deGroot at ripe.net>
X-Organization: RIPE Network Coordination Centre
X-Phone: +31 20 592 5065
Subject: Re: Hotel space in Munich
In-Reply-To: Your message of "Tue, 15 Apr 1997 19:05:36 EST."
<9703158611.AA861157240 at ncr.disa.mil>
Date: Wed, 16 Apr 1997 12:17:12 +0200
X-Orig-Sender: GeertJan.deGroot at ripe.net
Source-Info: From (or Sender) name not authenticated.
On Tue, 15 Apr 97 19:05:36 EST Bill Flanigan wrote:
> 3. Then there's the price of air travel. I'm afraid to ask if
> there is an IETF airfare group rate!
I don't think this is fair to complain about.
For the last thirty-and-some IETF's that were held in the USA,
no IETF group air fares were available for international flights,
so the foreign attendees had to take the full charge.
I think it's fair that this problem is reversed every so often.
Geert Jan
Received: from ietf.org by ietf.org id aa14411; 16 Apr 97 6:49 EDT
Received: from email.archlab.tuwien.ac.at by ietf.org id aa14349;
16 Apr 97 6:48 EDT
Received: by email.archlab.tuwien.ac.at (950413.SGI.8.6.12/940406.SGI.AUTO)
id MAA08141; Wed, 16 Apr 1997 12:45:35 +0200
Date: Wed, 16 Apr 1997 12:45:35 +0200 (MDT)
Sender:ietf-request at ietf.org
From: Sascha Ignjatovic <signato at email.archlab.tuwien.ac.at>
To: ietf at ietf.org
Subject: Re: Re[2]: Hotel space in Munich
In-Reply-To: <199704160709.AAA10002 at zocalo.net>
Message-ID: <Pine.SGI.3.91.970416123119.8038A-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.
but it would be a nice service from the local host of the meeting to
provide the ietf folks male and female :-) with the informations
how much hotels are there what they costs whats the contact phone etc. is
it will much easyer the wholle thing
imagine that every indivudual hase to check all this infos again and again
mybe the organizers intend to do that but to a later time point
in this case i thank to them in advance
sasha
ps.this kind of work should be done by the local organizers and it will be
apreciated so much and make our lives more intelligent
sory for beeing so "clever" :-) in reality i am not
Received: from ietf.org by ietf.org id aa16815; 16 Apr 97 7:59 EDT
Received: from lint.cisco.com by ietf.org id aa16575; 16 Apr 97 7:50 EDT
Received: from big-dawgs.cisco.com (herndon-dhcp-96.cisco.com [171.68.53.96]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id EAA23632; Wed, 16 Apr 1997 04:45:03 -0700 (PDT)
Message-Id: <3.0.1.32.19970416074501.007058f4 at lint.cisco.com>
X-Sender: pferguso at lint.cisco.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 16 Apr 1997 07:45:01 -0400
To: Geert Jan de Groot <GeertJan.deGroot at ripe.net>
Sender:ietf-request at ietf.org
From: Paul Ferguson <pferguso at cisco.com>
Subject: Re: Hotel space in Munich
Cc: ietf at ietf.org
In-Reply-To: <199704161017.MAA02294 at x0.ripe.net>
References: <Your message of "Tue, 15 Apr 1997 19:05:36 EST." <9703158611.AA861157240 at ncr.disa.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
At 12:17 PM 4/16/97 +0200, Geert Jan de Groot wrote:
>
>I don't think this is fair to complain about.
>For the last thirty-and-some IETF's that were held in the USA,
>no IETF group air fares were available for international flights,
>so the foreign attendees had to take the full charge.
>
>I think it's fair that this problem is reversed every so often.
>
I think so, too. Americans are whiners, aren't they? :-)
- paul
Received: from ietf.org by ietf.org id aa18462; 16 Apr 97 8:32 EDT
Received: from jazz.viagenie.qc.ca by ietf.org id aa18407; 16 Apr 97 8:30 EDT
Received: from [199.84.128.108] by jazz.viagenie.qc.ca (VG1.0/Viagenie)
id IAA11964; Wed, 16 Apr 1997 08:27:03 -0400
Date: Wed, 16 Apr 1997 08:27:03 -0400
X-Sender: blanchet at mail.viagenie.qc.ca
Message-Id: <v03007803af7a2f889601 at [199.84.128.108]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Marc Blanchet <Marc.Blanchet at viagenie.qc.ca>
Subject: hotel space in munich: no problem at the moment
Source-Info: From (or Sender) name not authenticated.
Hi,
just to say that I made my reservation a few minutes ago and got no
problem to reserve my room at the special ietf rate (185DM/single,
210DM/double). So I haven't seen a problem. But you should call directly
the hotel (011 49 89 9264 0).
Regards, Marc.
-------------------------------------------------------------------------
Marc Blanchet | Marc.Blanchet at viagenie.qc.ca
ViaGenie inc. | NIC: MB841
3107 ave. des hotels | radio: VA2-JAZ
Ste-Foy, Quebec, Canada |
G1W 4W5 | tel.: 418-656-9254
http://www.viagenie.qc.ca | fax.: 418-656-0183
-------------------------------------------------------------------------
Auteur du livre "TCP/IP simplifi", Editions Logiques,1997.
-------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa19125; 16 Apr 97 8:46 EDT
Received: from caladan.arrakis.es by ietf.org id aa19051; 16 Apr 97 8:45 EDT
Received: from pc-de-raides-j. (ie-37.arrakis.es [195.5.74.37]) by arrakis.es (8.7.5/8.7.3) with SMTP id OAA07246 for <ietf at ietf.org>; Wed, 16 Apr 1997 14:42:31 +0200 (MET DST)
Message-Id: <199704161242.OAA07246 at arrakis.es>
Comments: Authenticated sender is <raidesj at pop3.arrakis.es>
Sender:ietf-request at ietf.org
From: Dr-X <raidesj at arrakis.es>
Organization: Dr-X Enterprises, Ltd.
To: ietf at ietf.org
Date: Wed, 16 Apr 1997 13:44:30 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: Quoted-printable
Subject: Re: Hotel space in Munich
Priority: normal
In-reply-to: <9704152016.AA04842 at katahdin.columbia.sparta.com>
X-mailer: Pegasus Mail for Win32 (v2.53/R1)
Source-Info: From (or Sender) name not authenticated.
> Just got back from Memphis and had my travel agent try to make a
> hotel reservation for me at the Sheraton Munich. Guess what - all
> the IETF rate rooms are already gone. However, they did offer a room
> for DM 239 (wasn't that kind of them).
>
> OK - what's the backup hotel?
>
> Howard Weiss
>
> --
> ___________________________________________________________________
> | |
> |Howard Weiss phone (410) 381-9400 x201 |
> |SPARTA, Inc. (301) 621-8145 x201 (DC)|
> |9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 |
> |Columbia, MD 21046 email: hsw at columbia.sparta.com|
> |___________________________________________________________________|
>
Oh, damn! I have added myself to the mailing list of the IETF in
hoping that this way I'll be able to get the latest news on
technological facts just from the people who were doin' it and also
try to, once I got the subject, contribute myself with new and wild
ideas just to aid not to forget important
end-user-satisfaction-related affairs wich can make a very good
sounding standard to go wild or straight to rubbish... But, you know
what I've got so far??? More than 15 new e-mails daily complaining
about the lack of IETF-rate rooms for a convention - i.e. big
children crying because they don't like the skin colour of their new
teddy bear! ... Jesus! And worse of that, they=B4re supposed to be the
creators of the new technologies to make the Internet advance!!
Unbelievable! If I tell this to my friends free-lance programmers
and tech-freaks as I am they will take me for a fool or a lier!
No comments! =3D:-{
XXX XXX
DDDD RRRR XX XX
D D R R XX XX
D D R R XX XX
D D RRRR =3D=3D=3D=3D=3D XXXX ... ON THE EDGE OF TEC=
HNOLOGY
D D R R XX XX
D D R R XX XX
DDDD R R XX XX
XXX XXX
Received: from ietf.org by ietf.org id aa19283; 16 Apr 97 8:48 EDT
Received: from postman.adn.alcatel.com by ietf.org id aa19202;
16 Apr 97 8:47 EDT
Received: from by adn.alcatel.com with SMTP
(1.40.112.8/16.2) id AA027634644; Wed, 16 Apr 1997 08:44:04 -0400
Sender:ietf-request at ietf.org
From: Steve.Silverman at adn.alcatel.com
X-Openmail-Hops: 1
Date: Wed, 16 Apr 97 08:43:57 -0400
Message-Id: <H00004dc00703117 at MHS>
In-Reply-To: <3.0.1.32.19970416074501.007058f4 at lint.cisco.com>
Subject: Re: Hotel space
Mime-Version: 1.0
To: ietf at ietf.org
Content-Type: text/plain; charset=US-ASCII; name="Re:"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
I would like to suggest that the hosting organization (or the IETF
secretariat if the hosting organization can't do it) provides a list of
hotels in the area of the meeting (with travel and contact info).
If one misses the meeting site, it can be difficult, without local maps
or directories (even with a language problem) to find a place. Some
inexpensive Bed & Breakasts might appeal to some travelers.
In this case, Munich in August is a major tourist attraction and I would
expect hotel space to be difficult to find.
As far as a group air rate, since for any meeting, people are traveling
from many different places and at different times, any sort of charter
flight is out of the question. My recommended strategy is to fly early
and spend Saturday night in Munich, providing a large discount on the
air fare and providing some time to see the city.
Steve
Received: from ietf.org by ietf.org id aa20395; 16 Apr 97 9:02 EDT
Received: from cnri by ietf.org id aa20312; 16 Apr 97 9:01 EDT
Received: from ibp.ibp.fr by CNRI.Reston.VA.US id aa10491; 16 Apr 97 9:01 EDT
Received: from laios.ibp.fr (laios.ibp.fr [132.227.61.42])
by ibp.ibp.fr (8.8.5/jtpda-5.2) with SMTP id OAA01898
; Wed, 16 Apr 1997 14:56:46 +0200 (MET DST)
Message-Id: <3.0.32.19970415195647.00770c7c at hera.ibp.fr>
X-Sender: sf at hera.ibp.fr
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 16 Apr 1997 14:52:59 +0200
To: prism at prism.uvsq.fr, cost237members at norcontel.ie, bcousin at irisa.fr,
Walid.Dabbous at sophia.inria.fr, Christophe.Diot at sophia.inria.fr,
diaz at laas.fr, rolin at rsm.enst-bretagne.fr, Guy.Pujolle at prism.uvsq.fr,
Serge.Fdida at masi.ibp.fr, Eric.Horlait at masi.ibp.fr,
pansiot at succube.u-strasbg.fr, erbi at eurecom.fr, thai at masi.ibp.fr,
anelli at masi.ibp.fr, rezende at masi.ibp.fr, vv at lri.lri.fr,
hachicha at huffmann.esigetel.fr, hipparch at sophia.inria.fr,
ietf at CNRI.Reston.VA.US, reres at laas.fr, hans.eriksson at era-t.ericsson.se,
tubach at cal.enst.fr, Miklos.Boda at era-t.ericsson.se, alinef at vnet.ibm.com,
caro at nortel.co.uk, guillemi at lannion.cnet.fr, HENK at bme-tel.ttt.bme.hu,
labetoul at eurecom.fr, raif_onvural at alliedtelesyn.com,
Patrick.Cocquet at dassault-elec.fr, vijay at raleigh.ibm.com,
znaty at rennes.enst-bretagne.fr, roberts at issy.cnet.fr, ninatp at erg.sri.com
Sender:ietf-request at ietf.org
From: Serge Fdida <Serge.Fdida at masi.ibp.fr>
Subject: ECMAST'97
Cc: Serge.Fdida at masi.ibp.fr
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
-----------------------------------------------------------------------
ECMAST*97,
-----------------------------------------------------------------------
European Conference on Multimedia Applications, Services and Techniques
-----------------------------------------------------------------------
May 21-23, 1997, Milano, Italy
+ 15 TECHNICAL SESSIONS and 48 Paper Presentations covering the most
hot topics on Multimedia: Multimedia Networks, Services and Protocols,
Broadcast Delivery, Internet, Terminals and Servers, Trials, Content
Creation and Integration, Coded Representation;
+ TECHNICAL VISITS to Multimedia Trials, ATM Platforms and TV
programmes production studios;
+ KEYNOTE SPEECH on "Nomadic Computing" given by Prof. L. Kleinrock
(University of California Los Angeles);
+ TUTORIALS on key issues: Intelligent Physical Agents, Advanced
Internet Protocols, DAVIC 1.2 and Switching in Internet;
+ WORKSHOP on "Synthetic/Natural Hybrid Coding";
+ EXHIBITIONS and DEMONSTRATIONS
Details and Registration Forms available on:
--------------------------------------------
http://www.italtel.it/drsc/ecmast97/head.htm
--------------------------------------------
------------------------------------------------------------------------
Serge Fdida tel: 01 44 27 30 58
Universite Pierre et Marie Curie fax: 01 44 27 62 86
Laboratoire LIP6-CNRS mail: Serge.Fdida at masi.ibp.fr
4, Place Jussieu web: http://www-masi-net.ibp.fr/~sf
75252 Paris Cedex 05
France
Received: from ietf.org by ietf.org id aa25912; 16 Apr 97 10:39 EDT
Received: from ietf.ietf.org by ietf.org id aa25172; 16 Apr 97 10:34 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-chitra-rether-00.txt
Date: Wed, 16 Apr 1997 10:34:30 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704161034.aa25172 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : RETHER : A Protocol for Real-Time
Traffic Support on Ethernet
Author(s) : C. Venkatramani, T. Chiueh
Filename : draft-chitra-rether-00.txt
Pages : 22
Date : 04/14/1997
Distributed multimedia applications require performance guarantees from the
underlying network subsystem. Ethernet has been the dominant local area
network architecture in the last decade, and we believe that it will remain
popular because of its cost-effectiveness and the availability of
higher-bandwidth Ethernets. We present the design of a software-based
timed-token protocol called RETHER that provides real-time performance
guarantees to multimedia applications without requiring any modifications
to existing Ethernet hardware. RETHER features a hybrid mode of operation
to reduce the performance impact on non-real-time network traffic, a
race-condition-free distributed admission control mechanism, and an
efficient token-passing scheme that protects the network against token loss
due to node failures or otherwise. Performance measurements from a
prototype running on 10-Mbps Ethernet and 100-Mbps Fast-Ethernet indicate
that up to 60 of the raw bandwidth can be reserved without deteriorating
the performance of non-real-time traffic significantly. This scheme is
consistent with the ISSLL over LANs framework 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-chitra-rether-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-chitra-rether-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-chitra-rether-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: <19970416103318.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-chitra-rether-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-chitra-rether-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970416103318.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25911; 16 Apr 97 10:39 EDT
Received: from ietf.ietf.org by ietf.org id aa25295; 16 Apr 97 10:34 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-barber-nntp-imp-07.txt
Date: Wed, 16 Apr 1997 10:34:45 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704161034.aa25295 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Common NNTP Extensions
Author(s) : S. Barber
Filename : draft-barber-nntp-imp-07.txt
Pages : 25
Date : 04/14/1997
In this document, a number of popular extensions to the NNTP protocol
defined in RFC977 are documented and discussed. While this document is not
intended to serve as a standard of any kind, it will hopefully serve as a
reference document for future implementers of the NNTP protocol. In the
role, this document would hopefully create the possibility for some level
of interoperability among implementations that make use of 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-barber-nntp-imp-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-barber-nntp-imp-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-barber-nntp-imp-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: <19970414170906.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-barber-nntp-imp-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-barber-nntp-imp-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970414170906.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25908; 16 Apr 97 10:39 EDT
Received: from ietf.ietf.org by ietf.org id aa25219; 16 Apr 97 10:34 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-mib-02.txt
Date: Wed, 16 Apr 1997 10:34:38 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704161034.aa25219 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internetworking Over NBMA
Working Group of the IETF.
Title : Definitions of Managed Objects for Classical IP and ARP
Over ATM Using SMIv2
Author(s) : M. Greene, J. Luciani, K. White, T. Kuo
Filename : draft-ietf-ion-mib-02.txt
Pages : 38
Date : 04/14/1997
The purpose of this memo is to define the Management Information Base (MIB)
for supporting Classical IP and ARP over ATM as specified in Classical IP
and ARP over ATM, refer to reference [3]. Support of an ATM interface by an
IP layer will require implementation of objects from several Managed
Information Bases (MIBs) as well as their enhancement in order to enable
usage of ATM transports. It is the intent of this MIB to fully adhere to
all prerequisite MIBs unless explicitly stated. Deviations will be
documented in corresponding conformance statements. The specification of
this MIB will utilize the Structure of Management Information (SMI) for
Version 2 of the Simple Network Management Protocol Version (refer to
RFC1902, reference [1]).
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ion-mib-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-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-ion-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: <19970414170223.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-mib-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-mib-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970414170223.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25913; 16 Apr 97 10:39 EDT
Received: from ietf.ietf.org by ietf.org id aa25397; 16 Apr 97 10:34 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-anderson-docs-rf-mib-00.txt
Date: Wed, 16 Apr 1997 10:34:53 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704161034.aa25397 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Data Over Cable Service (DOCS) Radio Frequency (RF)
Interface Management Information Base (MIB)
Author(s) : P. Anderson, W. Sawyer, R. Woundy
Filename : draft-anderson-docs-rf-mib-00.txt
Pages : 77
Date : 04/14/1997
This Internet-Draft outlines the Radio Frequency (RF) Interface Management
Information Bases (MIBs) for high-speed data-over-cable systems developed
by the MCNS Data Over Cable Services working group.
Two Simple Network Management Protocol (SNMP) MIBs are defined. The first
is the MCNS Interface MIB and defines objects that enable management of the
CATV MAC and PHY layer interfaces. The second is the MCNS Cable Modem (CM)
MIB and defines objects that enable management of CMs and Cable Modem
Termination Systems (CMTSs).
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-anderson-docs-rf-mib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-anderson-docs-rf-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-anderson-docs-rf-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: <19970414172056.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-anderson-docs-rf-mib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-anderson-docs-rf-mib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970414172056.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25909; 16 Apr 97 10:39 EDT
Received: from WLV.IIPO.GTEGSC.COM by ietf.org id aa25605; 16 Apr 97 10:36 EDT
Received: from SPIELZEUG.IIPO.GTEGSC.COM (SPIELZEUG.IIPO.GTEGSC.COM [199.107.242.241]) by wlv.iipo.gtegsc.com (8.8.5/8.7.3) with SMTP id HAA07269; Wed, 16 Apr 1997 07:21:15 -0700 (PDT)
Date: Wed, 16 Apr 1997 07:20:48 -0700 (PDT)
Sender:ietf-request at ietf.org
From: Merton Campbell Crockett <mcc at wlv.iipo.gtegsc.com>
To: Steve.Silverman at adn.alcatel.com
cc: ietf at ietf.org
Subject: Re: Hotel space
In-Reply-To: <H00004dc00703117 at MHS>
Message-ID: <Pine.WNT.3.96.970416070852.-1039539F-100000 at SPIELZEUG.IIPO.GTEGSC.COM>
X-X-Sender: mcc at wlv.iipo.gtegsc.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Why not look at <http://www.muenchen.de/> "Die Stadt Informiert"? It
provides online information about Landeshauptstadt Muenchen. It's important
to remember that there is public transportation that "works" so its not a
big deal to stay 50 km from Stadt Mitte. Unless things have changed
significantly, Fruhstuck (breakfast) is included at most hotels. The
exception being the "Americanized" hotels at which one doesn't want to stay.
Too many Americans stay there.
Merton Campbell Crockett
GTE Government Systems, ESD/IOO
On Wed, 16 Apr 1997 Steve.Silverman at adn.alcatel.com wrote:
} I would like to suggest that the hosting organization (or the IETF
} secretariat if the hosting organization can't do it) provides a list of
} hotels in the area of the meeting (with travel and contact info).
} If one misses the meeting site, it can be difficult, without local maps
} or directories (even with a language problem) to find a place. Some
} inexpensive Bed & Breakasts might appeal to some travelers.
}
} In this case, Munich in August is a major tourist attraction and I would
} expect hotel space to be difficult to find.
}
} As far as a group air rate, since for any meeting, people are traveling
} from many different places and at different times, any sort of charter
} flight is out of the question. My recommended strategy is to fly early
} and spend Saturday night in Munich, providing a large discount on the
} air fare and providing some time to see the city.
}
} Steve
}
}
Received: from ietf.org by ietf.org id aa25910; 16 Apr 97 10:39 EDT
Received: from ietf.ietf.org by ietf.org id aa25267; 16 Apr 97 10:34 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-interserver-alt-00.txt
Date: Wed, 16 Apr 1997 10:34:42 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704161034.aa25267 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 Dynamic Host Configuration
Working Group of the IETF.
Title : An Inter-server Protocol for DHCP
Author(s) : R. Droms, K. Kinnear
Filename : draft-ietf-dhc-interserver-alt-00.txt
Pages : 53
Date : 04/14/1997
The DHCP protocol is designed to allow for multiple DHCP servers, so that
reliability of DHCP service can be improved through the use of redundant
servers. To provide redundant service, all of the DHCP servers must be
configured with the same information about assigned IP addresses and
parameters; i.e., all of the servers must be configured with the same
bindings. Because DHCP servers may dynamically assign new addresses or
configuration parameters, or extend the lease on an existing address
assignment, the bindings on some servers may become out of date. The DHCP
inter-server protocol provides an automatic mechanism for synchronization
of the bindings stored on a set of cooperating DHCP servers.
This draft is a direct extension of draft-ietf-dhc-interserver-00.txt, but
has been renamed draft-ietf-dhc-interserver-alt-00.txt since an alternative
proposal (also a direct extension of draft-ietf-dhc-interserver-00.txt but
in a different direction) exists named draft-ietf-dhc-interserver-01.txt.
Internet-Drafts are available by anonymous FTP. 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-interserver-alt-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-interserver-alt-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-dhc-interserver-alt-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: <19970414170636.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-interserver-alt-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-interserver-alt-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970414170636.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25907; 16 Apr 97 10:39 EDT
Received: from ietf.ietf.org by ietf.org id aa25349; 16 Apr 97 10:34 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-gahrns-imap-practice-01.txt
Date: Wed, 16 Apr 1997 10:34:48 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704161034.aa25349 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IMAP4 Multi-Accessed Mailbox Practice
Author(s) : M. Gahrns
Filename : draft-gahrns-imap-practice-01.txt
Pages : 12
Date : 04/14/1997
IMAP4[rfc2060] is rich client/server protocol that allows a client to
access and manipulate electronic mail messages on a server. Within the
protocol framework, it is possible to have differing results for particular
client/server interactions. If a protocol does not allow for this, it is
often unduly restrictive.
For example, when multiple clients are accessing a mailbox and one
attempts to delete the mailbox, an IMAP4 server may choose to implement
a solution based upon server architectural constraints or
individual preference.
With this flexibility comes greater client responsibility. It is not
sufficient for a client to be written based upon the behavior of
a particular IMAP server. Rather the client must be based upon
the behavior allowed by the protocol.
By documenting common IMAP4 server practice for the case of simultaneous
client access to a mailbox, we hope to ensure the widest amount of
inter-operation between IMAP4 clients and 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-gahrns-imap-practice-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-gahrns-imap-practice-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-gahrns-imap-practice-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: <19970414171504.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-gahrns-imap-practice-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-gahrns-imap-practice-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970414171504.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26974; 16 Apr 97 10:52 EDT
Received: from survis.surfnet.nl by ietf.org id aa26853; 16 Apr 97 10:50 EDT
Received: from surah.surfnet.nl by survis.surfnet.nl with SMTP (PP) with ESMTP;
Wed, 16 Apr 1997 16:46:52 +0200
Received: from surfnet.nl (actually host surah.surfnet.nl)
by surah.surfnet.nl with SMTP (PP) with ESMTP;
Wed, 16 Apr 1997 16:46:49 +0200
To: Bill Woodcock <woody at zocalo.net>
cc: ietf at ietf.org
Subject: Re: Re[2]: Hotel space in Munich
In-reply-to: Your message of "Wed, 16 Apr 1997 00:09:48 PDT." <199704160709.AAA10002 at zocalo.net>
Organisation: SURFnet ExpertiseCentrum bv
Address: Radboudburcht, P.O. Box 19115, 3501 DC Utrecht, NL
Phone: +31 302 305 305
Telefax: +31 302 305 329
X-url: http://www.sec.nl/persons/huizer/
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8559.861202008.1 at surfnet.nl>
Date: Wed, 16 Apr 1997 16:46:48 +0200
Sender:ietf-request at ietf.org
From: Erik Huizer <Erik.Huizer at sec.nl>
Message-ID: <9704161050.aa26853 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
For alternative accomodation see:
http://www.munich-tourist.de/
Erik
Received: from ietf.org by ietf.org id aa04257; 16 Apr 97 12:04 EDT
Received: from aland.bbn.com by ietf.org id aa04153; 16 Apr 97 12:02 EDT
Received: (from craig at localhost) by aland.bbn.com (8.7.1/8.7.1) id IAA14143; Wed, 16 Apr 1997 08:59:25 -0700 (PDT)
Message-Id: <199704161559.IAA14143 at aland.bbn.com>
To: ietf at ietf.org
Subject: Munich on Sunday
In-reply-to: Your message of Wed, 16 Apr 97 08:43:57 -0400.
<H00004dc00703117 at MHS>
Date: Wed, 16 Apr 97 08:59:24 -0700
Sender:ietf-request at ietf.org
From: Craig Partridge <craig at aland.bbn.com>
Source-Info: From (or Sender) name not authenticated.
Question for our Munich hosts which is likely to be of interest to
anyone going to Munich.
I haven't been in Germany for a while. Is it still the case that many
museums, restaurants, etc., shut down on Sundays? (My rule in Germany was
that Sunday was a good day for hiking -- and there's great hiking around
Munich).
Is this still true? Should I be thinking of driving (or taking a train)
to the Alps? Or will there be plenty to do in Munich itself on the Sunday
before IETF?
Craig
Received: from ietf.org by ietf.org id aa06692; 16 Apr 97 12:43 EDT
Received: from hail.ncr.disa.mil by ietf.org id aa06629; 16 Apr 97 12:41 EDT
Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id MAA19849 for <ietf at ietf.org>; Wed, 16 Apr 1997 12:35:55 -0400 (EDT)
Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01)
id AA861219461; Wed, 16 Apr 97 12:34:47 EST
Date: Wed, 16 Apr 97 12:34:47 EST
Sender:ietf-request at ietf.org
From: Bill Flanigan <flanigab at ncr.disa.mil>
Message-Id: <9703168612.AA861219461 at ncr.disa.mil>
To: ietf at ietf.org
Subject: Call Sheraton Munich Direct (Was: Re[4]: Hotel space Munich)
Source-Info: From (or Sender) name not authenticated.
Hi Bill,
1. As a reformed whiner (but confirmed German-vintage winer), you
are 100 percent correct!
2. Forget travel agents and the Sheraton US watts 800 number--they
are clueless.
3. Call the hotel directly at (from the US): 011-49-89-9264-0, and
ask for Reservations. They immediately know what the IETF is, and the
rates as posted at the IETF ftp site are correct and still available.
VAT is included.
4. Munich time is six hours ahead of US EDT.
5. Thanks for setting us straight.
Bill Flanigan
______________________________ Reply Separator _________________________________
Subject: Re: Re[2]: Hotel space in Munich
Author: Bill Woodcock <woody at zocalo.net> at smtp
Date: 4/16/97 5:39 AM
Oh, come on... Did any of you whiners actually bother to call the
hotel? They've got plenty of rooms left, and they'll happily give
them to you at the stated rate of 185 DM/night, which as has been
pointed out, is only $110/night. You'd be lucky to get anything
better than a Travelodge or Best Western at that price in the U.S.
-Bill
______________________________________________________________________________
bill woodcock woody at zocalo.net woody at nowhere.loopback.edu user at host.domain.com
Received: from cnri by ietf.org id aa06960; 16 Apr 97 12:49 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15631;
16 Apr 97 12:49 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <PAA25501 at pad-thai.cam.ov.com>; Wed, 16 Apr 1997 15:02:23 GMT
Message-Id: <3354E9D5.F2E at csc.com>
Date: Wed, 16 Apr 1997 11:01:41 -0400
From: Gene Hilborn <ghilborn at csc.com>
Organization: -
X-Mailer: Mozilla 3.01 (Win95; U)
Mime-Version: 1.0
To: Clifford Neuman <bcn at isi.edu>, cat-ietf at mit.edu
Subject: Re: RFC 1510 Revision - References
References: <3353EE31.1C40 at csc.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Addendum: The "DES MODES OF OPERATION" standard is FIPS-PUB-81.
-Gene
Received: from ietf.org by ietf.org id aa08597; 16 Apr 97 13:16 EDT
Received: from cs.columbia.edu by ietf.org id aa08459; 16 Apr 97 13:14 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 NAA17961; Wed, 16 Apr 1997 13:10:43 -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 NAA15015; Wed, 16 Apr 1997 13:10:41 -0400 (EDT)
X-Orig-Sender: hgs at cs.columbia.edu
Message-ID: <33550811.5DA3 at cs.columbia.edu>
Date: Wed, 16 Apr 1997 13:10:41 -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: Munich on Sunday
References: <199704161559.IAA14143 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:
>
> Question for our Munich hosts which is likely to be of interest to
> anyone going to Munich.
>
> I haven't been in Germany for a while. Is it still the case that many
> museums, restaurants, etc., shut down on Sundays? (My rule in Germany was
> that Sunday was a good day for hiking -- and there's great hiking around
> Munich).
Not Sunday. Typical closing day for museums and some restaurants is
Monday or Tuesday. However, stores won't be open on Sunday, with rare
exceptions.
>
> Is this still true? Should I be thinking of driving (or taking a train)
> to the Alps? Or will there be plenty to do in Munich itself on the Sunday
> before IETF?
>
> Craig
--
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 aa09049; 16 Apr 97 13:20 EDT
Received: from ietf.ietf.org by ietf.org id aa08987; 16 Apr 97 13:19 EDT
To: IETF-Announce: ;
Subject: 39th IETF: Munich, Germany - Hotel Information
Date: Wed, 16 Apr 1997 13:19:57 -0400
Sender:ietf-announce-request at ietf.org
From: Marcia Beaulieu <mbeaulie at ietf.org>
Message-ID: <9704161319.aa08987 at ietf.org>
NOTE: Reservations must be made by calling or faxing the hotel directly.
39th INTERNET ENGINEERING TASK FORCE Date: April 16, 1997
AT-A-GLANCE
DATES: August 11-15, 1997 HOST:
ISOC.DE
ietf39 at isoc.de
HOTEL/MEETING SITE: The Sheraton Munich
Abellastra. 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.
DM 185.00/single; DM 210.00/double
(All rates include a daily American Breakfast Buffet)
Specify: IETF Group
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
Received: from ietf.org by ietf.org id aa10275; 16 Apr 97 13:37 EDT
Received: from cnri by ietf.org id aa10185; 16 Apr 97 13:36 EDT
Received: from giasbg01.vsnl.net.in by CNRI.Reston.VA.US id aa16560;
16 Apr 97 13:35 EDT
Received: from [202.54.12.122] by giasbg01.vsnl.net.in; (5.65v3.2/1.1.8.2/20Feb95-0832PM)
id AA29639; Wed, 16 Apr 1997 22:58:33 +0500
Received: by baronhex with Microsoft Mail
id <01BC4AB9.B49CA060 at baronhex>; Wed, 16 Apr 1997 22:58:31 +-5-30
Message-Id: <01BC4AB9.B49CA060 at baronhex>
Sender:ietf-request at ietf.org
From: "Baron Hexa Pvt. Ltd." <baronhex at giasbg01.vsnl.net.in>
To: "'Serge.Fdida at masi.ibp.fr'" <Serge.Fdida at masi.ibp.fr>
Cc: "'alinef at vnet.ibm.com'" <alinef at vnet.ibm.com>,
"'anelli at masi.ibp.fr'" <anelli at masi.ibp.fr>,
"'bcousin at irisa.fr'" <bcousin at irisa.fr>,
"'caro at nortel.co.uk'" <caro at nortel.co.uk>,
"'Christophe.Diot at sophia.inria.fr'" <Christophe.Diot at sophia.inria.fr>,
"'cost237members at norcontel.ie'" <cost237members at norcontel.ie>
Cc: "'diaz at laas.fr'" <diaz at laas.fr>, "'erbi at eurecom.fr'" <erbi at eurecom.fr>,
"'Eric.Horlait at masi.ibp.fr'" <Eric.Horlait at masi.ibp.fr>,
"'guillemi at lannion.cnet.fr'" <guillemi at lannion.cnet.fr>,
"'Guy.Pujolle at prism.uvsq.fr'" <Guy.Pujolle at prism.uvsq.fr>,
"'hachicha at huffmann.esigetel.fr'" <hachicha at huffmann.esigetel.fr>
Cc: "'hans.eriksson at era-t.ericsson.se'" <hans.eriksson at era-t.ericsson.se>,
"'HENK at bme-tel.ttt.bme.hu'" <HENK at bme-tel.ttt.bme.hu>,
"'hipparch at sophia.inria.fr'" <hipparch at sophia.inria.fr>,
"'ietf at CNRI.Reston.VA.US'" <ietf at CNRI.Reston.VA.US>,
"'labetoul at eurecom.fr'" <labetoul at eurecom.fr>,
"'Miklos.Boda at era-t.ericsson.se'" <Miklos.Boda at era-t.ericsson.se>
Cc: "'ninatp at erg.sri.com'" <ninatp at erg.sri.com>,
"'pansiot at succube.u-strasbg.fr'" <pansiot at succube.u-strasbg.fr>,
"'Patrick.Cocquet at dassault-elec.fr'" <Patrick.Cocquet at dassault-elec.fr>,
"'prism at prism.uvsq.fr'" <prism at prism.uvsq.fr>,
"'raif_onvural at alliedtelesyn.com'" <raif_onvural at alliedtelesyn.com>,
"'reres at laas.fr'" <reres at laas.fr>
Cc: "'rezende at masi.ibp.fr'" <rezende at masi.ibp.fr>,
"'roberts at issy.cnet.fr'" <roberts at issy.cnet.fr>,
"'rolin at rsm.enst-bretagne.fr'" <rolin at rsm.enst-bretagne.fr>,
"'Serge.Fdida at masi.ibp.fr'" <Serge.Fdida at masi.ibp.fr>,
"'thai at masi.ibp.fr'" <thai at masi.ibp.fr>,
"'tubach at cal.enst.fr'" <tubach at cal.enst.fr>
Cc: "'vijay at raleigh.ibm.com'" <vijay at raleigh.ibm.com>,
"'vv at lri.lri.fr'" <vv at lri.lri.fr>,
"'Walid.Dabbous at sophia.inria.fr'" <Walid.Dabbous at sophia.inria.fr>,
"'znaty at rennes.enst-bretagne.fr'" <znaty at rennes.enst-bretagne.fr>
Subject: looking for partners - IETM/IPC's/CBT - Multimedia
Date: Wed, 16 Apr 1997 22:58:28 +-5-30
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BC4AB9.B4B69100"
Source-Info: From (or Sender) name not authenticated.
------ =_NextPart_000_01BC4AB9.B4B69100
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Dear Sir:
I send you this mail to explore a few ideas with your office. We are =
among India's leading Multimedia companies and I have enclosed a profile =
of our business for your reference. We have now become the first company =
outside of Europe, USA and ISrael to have developeed an IPC/IETM for an =
Aerosapce system (IAF - Aircraft). This has become a milestone.We =
develop applications in the areas: =20
a) IETM's/IPC's
b) CBT systems
c) Imaging databases
d) Internet/Intranet applications such as learning/CALS/Manufacturing
In the areas of IETM's/IPC's/CBT/ ship manuals systems we specialize in:
a) Content - Analysis and Design which is based on our methodology
b) Production - Authoring, Programming, Animation/Graphics, Content
c) Creative
d) Project Management
We look forward to exploring working together in the areas ofmentioned =
above and look forward to hearing from your office.=20
Regards,
Gerard J Rego
CEO
------ =_NextPart_000_01BC4AB9.B4B69100
Content-Type: application/octet-stream; name="Coprfl2.doc"
Content-Transfer-Encoding: base64
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAAABAAAAGAAAAAAAAAAA
EAAAGwAAAAEAAAD+////AAAAABkAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////9
////EQAAAP7///8SAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A
AAAQAAAAEwAAAP7////+////FAAAABUAAAAWAAAAFwAAAP7/////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////1IA
bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAWAAUA//////////8DAAAAAAkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAIZKPZw/NbwB
AwAAAEADAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAABIAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAYgAAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAf////8EAAAA/////wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAaIwAAAAAAAE8AYgBqAGUAYwB0AFAAbwBv
AGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEBAQAAAAIA
AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAACG8NqZPzW8AYbw2pk/NbwBAAAAAAAAAAAAAAAAAQAA
AP7///8DAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAA/v//////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////8BAP7/
AwoAAP////8ACQIAAAAAAMAAAAAAAABGHAAAAE1pY3Jvc29mdCBXb3JkIDYuMCBEb2N1bWVudAAK
AAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjYAAAAAADsAAwD+/wkABgAAAAAAAAAAAAAA
AQAAAAEAAAAAAP7/AAADCgAAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAA
AGgCAAAMAAAABwAAAJgAAAAIAAAA3AAAAAwAAAAAAQAACwAAACQBAAANAAAASAEAAA8AAABsAQAA
EAAAAJABAAAKAAAAtAEAABIAAADYAQAADgAAAPwBAAAJAAAAIAIAABMAAABEAgAA////////////
////////////////////////////////////////////////////HgAAAC4AAABGOlxNQVBQU1xN
U09GRklDRVxXSU5XT1JEXFRFTVBMQVRFXE5PUk1BTC5ET1QAAAAAAAAAAAAAAAAAAAAeAAAABAAA
AHNzcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAhvOWhdylZQAz
wAkEAAAAAGUAAAAAAAAAAAAAAAADAAAVGQAAGiMAAAAAAAAAAAAAAAAAAAAAAAAVFgAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAagAAAAAgAABqAAAAaiAAAAAAAABqIAAAAAAA
AGogAAAAAAAAaiAAAAAAAABqIAAAFAAAAMQgAAAAAAAAxCAAAAAAAADEIAAAAAAAAMQgAAAAAAAA
xCAAAAAAAADEIAAACgAAAM4gAAAQAAAAxCAAAAAAAABYIgAAVwAAAN4gAAAEAAAA4iAAAAAAAADi
IAAAAAAAAOIgAAAAAAAA4iAAAAAAAADiIAAAAAAAAOIgAAAAAAAA4iAAAAAAAAD+IAAAAgAAAAAh
AAAAAAAAACEAAAAAAAAAIQAAGgAAABohAACQAAAAqiEAAJAAAAA6IgAAHgAAAK8iAABUAAAAAyMA
ABcAAABYIgAAAAAAAAAAAAAAAAAAAAAAAAAAAABqIAAAAAAAAOIgAAAAAAAAAAANAA4AAQACAOIg
AAAAAAAA4iAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4iAAAAAAAADiIAAAAAAAAFgiAAAAAAAA4iAA
AAAAAABqIAAAAAAAAGogAAAAAAAA4iAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3iAAAAAAAADiIAAA
AAAAAOIgAAAAAAAA4iAAAAAAAADiIAAAAAAAAGogAAAAAAAA4iAAAAAAAABqIAAAAAAAAOIgAAAA
AAAA/iAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfiAAABoAAACYIAAALAAAAGogAAAAAAAAaiAAAAAA
AABqIAAAAAAAAGogAAAAAAAA4iAAAAAAAAD+IAAAAAAAAOIgAAAcAAAA4iAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEJhcm9uIEhleGEgaXMgb25lIG9mIEluZGlhJ3MgbGVhZGlu
ZyBNdWx0aW1lZGlhIFNvZnR3YXJlIGNvbXBhbnkgZGV2ZWxvcGluZyBjdXN0b21pemVkIE11bHRp
bWVkaWEgQXBwbGljYXRpb25zIGluIHRoZSBhcmVhJ3Mgb2YgIENvbXB1dGVyIEJhc2VkIFRyYWlu
aW5nIFN5c3RlbXMgLCBDb3Jwb3JhdGUgQ29tbXVuaWNhdGlvbnMgLCBJbnRlcmFjdGl2ZSBFbGVj
dHJvbmljIENhdGFsb2dzIChJRVRNJ3MvSVBDJ3MgLSBNSUwgU3BlY3MgZHJpdmVuKSwgUG9pbnQg
T2YgSW5mb3JtYXRpb24gVGVybWluYWxzIGFuZCBNdWx0aW1lZGlhIGRhdGFiYXNlIEFwcGxpY2F0
aW9ucy4NDUJhcm9uIEhleGEgd2FzIGZvdW5kZWQgaW4gU2VwdGVtYmVyIDkzIGFuZCBoYXMgYmVl
biBwaW9uZWVyaW5nIE11bHRpbWVkaWEgc2luY2UgdGhlbiBpbiBJbmRpYS4gSXQgaXMgYW4gICBv
cmdhbml6YXRpb24gIGZvdW5kZWQgYnkgZW50cmVwcmVuZXVycyBhbmQgaG91c2VzIG92ZXIgMjUg
cGVvcGxlLiBJdCBpcyBhIEJhbmdhbG9yZSBiYXNlZCBjb21wYW55IGFuZCBpcyBpbiB0aGUgcHJv
Y2VzcyBvZiBleHBhbmRpbmcgaXRzIGJ1c2luZXNzIGFsbCBvdmVyIHRoZSBjb3VudHJ5IC4gQmFy
b24gSGV4YSBoYXMgdG8gaXRzIGNyZWRpdCBhIHZlcnkgaGlnaCBwcm9maWxlIGxpc3Qgb2YgY3Vz
dG9tZXJzIHJhbmdpbmcgZnJvbSBGb3J0dW5lIDUwMCwgRGVmZW5zZSAsIEdvdmVybm1lbnQvUHVi
bGljIFNlY3RvciBFbnRlcnByaXNlIGFuZCBjb3Jwb3JhdGVzLg0NU29tZSBvZiB0aGUgY3VzdG9t
ZXJzIHRoYXQgQmFyb24gSGV4YSBoYXMgd29ya2VkIGZvciBhcmUgYXMgZm9sbG93cyA6DQ0gDSoq
IElUQyBMdGQuDSoqIEJBVEVMQ08gIChCYWhyYWluIFRlbGNvbSkNKiogVGhlIE5hZ2FyanVuYSBH
cm91cA0qKiBJQVQgKCBVU0EpDSoqIENvYXRzIEluZGlhIEx0ZC4NKiogQ0NTTA0qKiBNaW5pc3Ry
eSBvZiBEZWZlbmNlDSoqIEhpbmR1c3RhbiBBZXJvbmF1dGljcyBMaW1pdGVkICggMyBEaXZpc2lv
bnMgb2YgSEFMICkNKiogTmF0aW9uYWwgQWVyb25hdXRpY2FsIExhYm9yYXRvcnkNKiogQ2VudHJl
IGZvciBBZXJvbmF1dGljYWwgU3lzdGVtcywgU3R1ZGllcyBhbmQgIEFuYWx5c2lzDSoqIEFlcm9u
YXV0aWNhbCBEZXZlbG9wbWVudCBFc3RhYmxpc2htZW50DSoqIEFTSUVPDSoqIEFEQQ0qKiBUaGUg
R2FsbHVwIE9yZ2FuaXphdGlvbiANKiogV2lwcm8gIEluZm90ZWNoIA0qKiBLaXJsb3NrYXIgICBH
cm91cA0qKiBHcmluZHdlbGwgTm9ydG9uIEx0ZA0qKiAzU0UgDSoqIFRhdGEgLSBJQk0gKCBUSVNM
ICkNKiogR292ZXJubWVudCBvZiBLYXJuYXRha2ENKiogTWNEb3dlbGwgJiBDby5MdGQuKCBVQiBH
cm91cCkNKiogSW5kaWFuIEV4cHJlc3MNIA0MQnVzaW5lc3MgUGFydG5lcnMgOg0gDUVkQ0lMIC0g
R292dC5vZiBJbmRpYSBPcmdhbml6YXRpb24gdW5kZXIgdGhlIE1pbmlzdHJ5IG9mIEhSRC4gVGhl
IE1PVSB3aWxsIGJlIHRvIGRldmVsb3AgQ0JUL1NNSSBpbiBJbmRpYSBhbmQgaW4gb3RoZXIgY291
bnRyaWVzIGZvciBHb3Zlcm5tZW50IGRyaXZlbiBuZWVkcw0NDUNDU0wgLSBDYW5iYW5rIENvbXB1
dGVyIFNlcnZpY2VzIEx0ZC4gKCAgQSBjb25zb3J0aXVtIG9mIHNpeCBuYXRpb25hbGl6ZWQgSW5k
aWFuIEJhbmtzKQ0NVGhlIE1PVSBhbGxvd3MgYm90aCB0aGUgb3JnYW5pemF0aW9ucyB0byBsZXZl
cmFnZSB0aGUgc3RyZW5ndGhzIG9mIHRoZSBwYXJ0bmVyIGFuZCBkZXZlbG9wICBDQlQvU01JIHBy
b2R1Y3RzIGFuZCBjdXN0b21pemVkIHNlcnZpY2VzIGZvciBGaW5hbmNlL0JhbmtpbmcvSW5zdXJh
bmNlIGluIEluZGlhLg0NDUEgIEJyaWVmICBwcm9maWxlIG9mIG91ciBwZW9wbGU6DQ1DRU+ScyBi
YWNrZ3JvdW5kOiAgDQ1HZXJhcmQgSi4gUmVnbyBpcyB0aGUgY28tZm91bmRlciBhbmQgQ0VPIG9m
IEJhcm9uIEhleGEgUHZ0LiBMdGQuLCB3aGljaCBpcyBvbmUgb2YgdGhlIHBpb25lZXJpbmcgYW5k
IGxlYWRpbmcgTXVsdGltZWRpYSBzb2Z0d2FyZSBjb21wYW5pZXMgaW4gSW5kaWEuIFdpdGggYSBi
YWNrZ3JvdW5kIGluIElULCBNdWx0aW1lZGlhIChzaW5jZSA5MiksIEFJIGFuZCBFeHBlcnQgU3lz
dGVtcyBhbmQgTWFuYWdlbWVudCwgaGlzIGFyZWFzIG9mIGludGVyZXN0IGFuZCByZXNlYXJjaCBh
cmUgaW4gdGhlIGFyZWFzIG9mIEZ1dHVyZSBUaGlua2luZywgSW5kaWFuIGRldmVsb3BtZW50LCBQ
cm9ncmVzcywgQ2hhbmdlLCBBcHBsaWNhdGlvbiBvZiBOYXR1cmFsIGxpZmUgdG8gU3lzdGVtcyBF
bmdpbmVlcmluZywgQ3JlYXRpdml0eSBpbiBvcmdhbml6YXRpb25zIGFuZCBFbnZpcm9ubWVudHMs
IFdvbWVuIGluIFNvY2lldHksIEluZGlhbiBTb2Npb2Vjb25vbWljIGRldmVsb3BtZW50LCBFZHVj
YXRpb25hbCBNZXRob2RvbG9naWVzIGFuZCBSZXNlYXJjaCwgRWR1Y2F0aW9uYWwgdG9vbHMgYW5k
IFRlY2hub2xvZ2llcywgR0lJL05JSSAoR2xvYmFsL05hdGlvbmFsIEluZm9ybWF0aW9uIEluZnJh
c3RydWN0dXJlKSBJbmZvcm1hdGlvbiBFbnZpcm9ubWVudHMsIEluZm9ybWF0aW9uIFRlY2hub2xv
Z2llcywgQ29tbXVuaWNhdGlvbiB0ZWNobm9sb2dpZXMsICBWaXJ0dWFsIHJlYWxpdHksIEVtZXJn
aW5nIFRlY2hub2xvZ2llcywgVGVsZWNvbW11bmljYXRpb25zLCBNYWNoaW5lIHN5c3RlbXMgYW5k
IFJvYm90aWNzLCBNYW51ZmFjdHVyaW5nIHN5c3RlbXMsIFJpZ2h0cywgUHJpdmFjeSBhbmQgRnJl
ZWRvbSBvZiBJbmZvcm1hdGlvbiwgUG9saWN5IC0gRGV2ZWxvcG1lbnQsIEFwcGxpY2F0aW9uLCBS
ZXNlYXJjaCwgUHN5Y2hvbG9neSBhbmQgSHVtYW4gQmVoYXZpb3IsIFJvbGUgb2YgUGVvcGxlIGlu
IEVudmlyb25tZW50cyAtIFByaXZhdGUsIEJ1c2luZXNzLCBHb3Zlcm5tZW50IGFuZCBTb2NpZXR5
LCAgSW50ZXJhY3RpdmUgTGVhcm5pbmcgU3lzdGVtcywgSW1hZ2luZyBUZWNobm9sb2d5LCBCaW9s
b2dpY2FsIFN5c3RlbXMsIEVuZ2luZWVyaW5nLCBXb3JrZmxvdyBTeXN0ZW1zLCBUZWxlY29tbXVu
aWNhdGlvbiBzeXN0ZW1zLCBUZWxlLUVudmlyb25tZW50cywgSW5mb3JtYXRpb24gV2FyZmFyZSAt
IEJvdGggRWNvbm9taWMgYW5kIE1pbGl0YXJ5LCBCdXNpbmVzcyBhbmQgRnV0dXJlIFRlY2hub2xv
Z2llcywgTmF0aW9uYWwgU2VjdXJpdHkgaXNzdWVzLCBNaWxpdGFyeSBTdHJhdGVneS9Eb2N0cmlu
ZSBhbmQgV2FyZmFyZSwgV2VhcG9ucyBEZXNpZ24sIEVjb25vbWljIERldmVsb3BtZW50LCBGREks
IEVtZXJnaW5nIEVjb25vbXkgUmVzZWFyY2gsIENvbXBldGl0aXZlIEVjb25vbWljIGFuZCBCdXNp
bmVzcyBSZXNlYXJjaCwgQW5pbWFsIEJlaGF2aW9yLCBDb21tdW5pY2F0aW9uLCBQb3B1bGF0aW9u
IFN0dWRpZXMsIFNwYWNlIFJlc2VhcmNoLCBFbmdpbmVlcmluZyBhbmQgU3lzdGVtcywgRGlzdHJp
YnV0ZWQgTGVhcm5pbmcsIFZpcnR1YWwgU29jaWV0aWVzLCBCaW90ZWNobm9sb2d5LCBMYXcgLSBF
bGVjdHJvbmljLCBJbmZvcm1hdGlvbiwgTmV3IEdvdmVybm1lbnQsIFBvbGl0aWNhbCBzeXN0ZW1z
IC0gVG9kYXkgYW5kIFRvbW9ycm93LCAgdG8gbmFtZSBhIGZldy4gSW4gYWRkaXRpb24gdGhlIGF1
dGhvciBpcyBhIG1lbWJlciwgY29udHJpYnV0b3IgYW5kIEVkaXRvciBmb3IgbWFueSBuZXdzcGFw
ZXJzLCBtYWdhemluZXMgYW5kIGpvdXJuYWxzIGluIEluZGlhIGFuZCB3cml0ZXMgb24gdGhlIGFi
b3ZlIHRvcGljcy4gSGUgaXMgYWxzbyBhIHZpc2l0aW5nIGZhY3VsdHkgdG8gdGhlIElJTSAtIEIg
b24gSVQgYW5kIE11bHRpbWVkaWEuIFRoZSBhdXRob3IgaXMgYWxzbyBjdXJyZW50bHkgYXV0aG9y
aW5nIGJvb2tzIG9uIElUIGFuZCBNdWx0aW1lZGlhIGFwcGxpY2F0aW9ucyB3aXRoIGEgc3BlY2lm
aWMgZm9jdXMgb24gSW5kaWEgYW5kIEluZGlhbiBCdXNpbmVzcywgR292ZXJubWVudCBhbmQgcGVy
c29uYWwvSG9tZSBhcHBsaWNhdGlvbnMuICBUaGUgYXV0aG9yIGhhcyBhbHNvIGRlbGl2ZXJlZCBt
YW55IGxlY3R1cmVzIG9uIGludml0YXRpb24gdG8gSW5kdXN0cnksIEdvdmVybm1lbnQsIERlZmVu
c2UgJiBNaWxpdGFyeSBhbmQgRWR1Y2F0aW9uYWwgb3JnYW5pemF0aW9ucyBvbiB0aGUgYWJvdmUg
dG9waWNzLiBUaGUgYXV0aG9yIGlzIGFsc28gY3VycmVudGx5IGRldmVsb3BpbmcgYSBXaGl0ZSBQ
YXBlciBvbiBJbmRvLVVLIE11bHRpbWVkaWEgb3Bwb3J0dW5pdGllcyB3aGljaCBpcyBiZWluZyBw
cmVzZW50ZWQgdG8gdGhlIEJyaXRpc2ggTWluaXN0ZXIgb2YgU2NpZW5jZSAmIFRlY2hub2xvZ3kg
aW4gdGhlIFVLLiANDQ0NQW5pbCBLLiBSYW8gLSBDaGFpcm1hbiAmIE1hbmFnaW5nIERpcmVjdG9y
DQ1Fc3NlbnRpYWxseSAgYSAgYnVzaW5lc3NtYW4gIGJ5ICBwcm9mZXNzaW9uICB3aXRoICAgYSAg
YmFja2dyb3VuZCAgaW4gIGNvbW1lcmNlICwgIGhlICBoYXMgc3VjY2Vzc2Z1bGx5IGdyb3duIGFu
ZCBtYXR1cmVkIGludG8gdGhlIGFyZWFzIG9mIGhpcyBjb3JlIGNvbXBldGVuY2llcyBhbmQgaGFu
ZGxlcyBkaXZlcnNlIGJ1c2luZXNzZXMgZnJvbSBpbnRlcmlvciBkZWNvcmF0aW9uIHRvIG5vdyBJ
VCBhbmQgYSBuYXR1cmFsIGJ1c2luZXNzIGFjdW1lbi4gDQ0NSi5FLlJlZ28gLSAgSGVhZCAgTWFu
YWdlbWVudCBDb25zdWx0YW5jeSBHcm91cCANQi5Db20sIE0uQ29tLCAgTUlNQSwgTUlJTU0sIE1C
SU0oVUspLCBQR0RNTSwgUEdQcm9kTSwgUEdEQkEsDURTQURQLCBBU00sIEFGQShVSyksIE1JU1RE
LCBNQ1NJLCBESlBSLCBEREJNLCBNT1JTSS4NDVdpdGggICBhICBkaXZlcnNlICBiYWNrZ3JvdW5k
ICBmcm9tICBhcmVhcyAgb2YgIG1hbmFnZW1lbnQgIHN1Y2ggIGFzICBmaW5hbmNlICwgIHByb2R1
Y3Rpb24gcGxhbm5pbmcgIGFuZCAgY29udHJvbCAgdG8gIElUICBhbmQgIFB1YmxpYyAgUmVsYXRp
b25zICwgIGhlICBoZWFkcyAgY29uc3VsdGFuY3kgIGFuZCAgaXMgYSBrZXkgbWVtYmVyIG9mIG91
ciBzb2x1dGlvbnMgZ3JvdXAuIEhpcyBleHBlcmllbmNlIGluICBJbmRpYW4sIEdlcm1hbiwgQW1l
cmljYW4sICBCcml0aXNoIGFuZCBKYXBhbmVzZSBtYW5hZ2VtZW50IHN0eWxlcyBzdGFuZHMgdXMg
aW4gZ29vZCBzdGVhZCBpbiBvdXIgcHJvamVjdHMgYW5kIHNvbHV0aW9ucy4NDUFkdmlzb3JzOg0N
UHJvZi4gTS5KLiBYYXZpZXIgLSAgSUlNLiAgQmFuZ2Fsb3JlDUFuIGFkdmlzb3Igb24gb3VyIGJv
YXJkIGFuZCBwcm92aWRlcyBpbnB1dHMgaW4gYXJlYXMgb2YgTWFya2V0aW5nIGluIG91ciBzb2Z0
d2FyZSBhbmQgY29uc3VsdGluZy4NDVByb2YuICBSLiBOYXJheWFuc3dhbXkgLSBJSU0gQmFuZ2Fs
b3JlDVdvcmtzIGluIGFyZWFzIG9mIGZpbmFuY2Ugc3VjaCBhcyBBQkMgYW5kIGZvcm1zIGFuIGlu
dGVncmFsIHBhcnQgb2Ygb3VyIGNvbnN1bHRpbmcgdGVhbS4NDQ1UaGUgICAgcmVzdCAgICBvZiAg
ICAgb3VyICAgIHRlYW0gICBpcyAgIGNvbXByb21pc2VkICAgb2YgICAgaW5kaXZpZHVhbHMgICBm
cm9tICAgYmFja2dyb3VuZHMgICBpbiBNYW5hZ2VtZW50LCBJbnN0cnVjdGlvbmFsIERlc2lnbiwg
RW5naW5lZXJpbmcgLCBJVCAsICBQcm9ncmFtbWluZywgICBWaWRlbyAgIGFuZCAgIEF1ZGlvICBw
cm9kdWN0aW9uLCBTb2Npb2xvZ3kgYW5kIFBzeWNob2xvZ3ksIENyZWF0aXZlIGRlc2lnbiwgTWFy
a2V0aW5nIGFuZCBRdWFsaXR5IGFzc3VyYW5jZS4NDQ3QzxHgobEa4QAAAAAAAAAAAAAAAAAAAAA7
AAMA/v8JAAYAAAAAAAAAAAAAAAEAAAABAAAAAAAAAAAQAAACAAAAAQAAAP7///8AAAAAAAAAAP//
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////BQBTAHUAbQBtAGEAcgB5AEkA
bgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgD/////////
//////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAmAIAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/NbwBAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAADSSWsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAHgAAABMAAABNaWNyb3NvZnQgV29yZCA2LjAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAHgAAAAIAAAAyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAA
OwADAP7/CQAGAAAAAAAAAP//////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////wADAACBAwAAoQMAAD0GAABxCAAA
cggAAE4KAABfEgAAYRIAAPoSAACmEwAAqBMAAKkTAACqEwAA1hMAANcTAADYEwAA3BQAAA4VAADp
FgAA8xYAAA0XAAAPFwAAGBcAABkXAABIFwAAWhcAAHwXAACZFwAAohcAALIXAADIFwAA/BcAAP0X
AABgGAAAFBkAABUZAAD89/z3/Pf89/zy/Pf89/z3/Pf89+z3/PL89/zs9/z3/Pf89+oAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANdAAAKVYFd
AwBeAWMYAAAIXQMAXgFjGAAACFWBXQMAYxgAAAZdAwBjGAAkAAMAAEYEAABHBAAA9QUAAPYFAAA8
BgAAPQYAAD8GAABLBgAAaAYAAH8GAACNBgAAoQYAAKkGAADABgAA+AYAABwHAABWBwAAgAcAAIkH
AACQBwAArAcAAMAHAADVBwAA7QcAAPUHAAAMCAAAJwgAAEgIAABaCAAAXAgAAHEIAABzCAAAEAkA
ABEJAAASCQAAagkAAGsJAAAYCgAAGQoAABoKAAA7CgAAPAoAAFAKAABRCgAAqRMAAP4ABsAhDgH+
AAHAIQ4B/gAIwCEOAf4AAcAhDgH+AALAIQ4B/gABwCEOAf4AAcAhDgH+AAHAIQ4B/gABwCEOAf4A
AcAhDgH+AAHAIQ4B/gABwCEOAf4AAcAhDgH+AAHAIQ4B/gABwCEOAf4AAcAhDgH+AAHAIQ4B/gAB
wCEOAf4AAcAhDgH+AAHAIQ4B/gABwCEOAf4AAcAhDgH+AAHAIQ4B/gABwCEOAf4AAcAhDgH+AAHA
IQ4B/gABwCEOAf4AAcAhDgH+AAHAIQ4B/gABwCEOAf4AAAAAAAD+AAHAIQ4B/gADwCEOAf4AAcAh
DgH+AAHAIQ4B/gACwCEOAf4AAcAhDgH+AAPAIQ4B/gABwCEOAf4AAcAhDgH+AAHAIQ4B/gABwCEO
Af4AAcAhDgH+AAHAIQ4B/gAqwCEOAQAAAAAAAAAAAAEAAC2pEwAAqhMAAKsTAACsEwAA1xMAANgT
AADcFAAA3RQAAN4UAAAOFQAASxUAAIAVAACBFQAA6BYAAOkWAADzFgAA9BYAABkXAAB7FwAAfBcA
AKMXAAD8FwAA/RcAAP4XAAATGQAAFBkAABUZAAD+AAHAIQ4B/gABwCEOAf4AAcAhDgH+AAHAIQ4B
/gABwCEOAf4ABcAhDgH+AAHAIQ4B/gABwCEOAf4AAcAhDgH+AAHAIQ4B/gABwCEOAf4AAcAhDgH+
AAfAIQ4B/gABwCEOAf4AAcAhDgH+AAHAIQ4B/gABwCEOAf4AAsAhDgH+AAHAIQ4B/gABwCEOAf4A
AsAhDgH+AAHAIQ4B/gABwCEOAf4ABcAhDgH+AAHAIQ4B/gABwCHmAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAGg4ADwAIAAEASwAPAAAABAAaAABA8f8C
ABoABk5vcm1hbAACAAAAAwBhCQQAAAAAAAAAAAAAAAAAAAAAAAAAIgBBQPL/oQAiABZEZWZhdWx0
IFBhcmFncmFwaCBGb250AAAAAAAAAAAAAAAAAAAAFRYAAAUA/////wAA/////wQABCD//wEAACD/
/wIABCD//wMAACD//wQAAAAAAF0FAAC5DQAA/hQAABUWAAAAABQAAAABAPACAAACABUBAAADAAAA
AAAAAwAAFRkAAA0AAAMAAKkTAAAVGQAADgAPABUWAAAcAANzc3MVQzpcR0VSQVJEXENPUFJGTDIu
RE9D/0BFcHNvbiBMWC04MDAATFBUMToARVBTT045AEVwc29uIExYLTgwMAAAAAAAAAAAAAAAAAAA
AAAAAAAACgMMA0QATAADZgAAAQABAP4A/gBZgQEACAB4AAEAAQCQAAEA+gJygAEAVrkCAK2rGQAA
ABkAAAAAAAIAZAACAAAAAAAAAP//TTcAAEYMqgcdAAEAAAD//wAA//8AAP////8AAAAAAAD/////
/////0Vwc29uIExYLTgwMAAAAAAAAAAAAAAAAAAAAAAAAAAACgMMA0QATAADZgAAAQABAP4A/gBZ
gQEACAB4AAEAAQCQAAEA+gJygAEAVrkCAK2rGQAAABkAAAAAAAIAZAACAAAAAAAAAP//TTcAAEYM
qgcdAAEAAAD//wAA//8AAP////8AAAAAAAD//////////wMAAQBLAwAATQMAAAkAAIAAgEsDAAAB
AAAASwMAAFcAFRaQAQAAVGltZXMgTmV3IFJvbWFuAAwWkAECAFN5bWJvbAALJpABAABBcmlhbAAR
NZABAABDb3VyaWVyIE5ldwATIpABAABNUyBTYW5zIFNlcmlmAAAABAABAAgAAADQAgAAAAAAAAAA
AAAAAMGjE4YAAAAAAgADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAkAxcAAAAAAAAAAANzc3MAAAAAAAAAAAAA0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwAD
AP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAAEAAAAgAAAAEAAAD+////AAAAAAAAAAD/////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAP//////////AwAAAAAJ
AgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAACG7R6uPzW8AR0AAABAAwAAAAAAAAEAQwBvAG0AcABP
AGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIB
////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGIAAAAA
AAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAABoAAgH/////BAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAeAAAAOyMAAAAAAABPAGIAagBlAGMAdABQAG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgABAQEAAAACAAAA/////wAAAAAAAAAAAAAAAAAAAAAA
AAAAhvDamT81vAGG8NqZPzW8AQAAAAAAAAAAAAAAAP//////////////////////////////////
/////////////////////////////w0AAAAOAAAADwAAABAAAAATAAAA//////////8UAAAAFQAA
ACYAAAD//////////xoAAAD9/////v////7////+////HAAAAB8AAAAgAAAAIQAAACIAAAAjAAAA
JAAAACUAAAAMAAAAJwAAAP7/////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////BQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBt
AGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgD///////////////8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAmAIAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//
/////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA/v///wMAAAAEAAAABQAAAAYAAAAHAAAA
CAAAAAkAAAAKAAAACwAAAAwAAAD+////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////z81vAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAABAAAAAABgNjwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeAAAAEwAA
AE1pY3Jvc29mdCBXb3JkIDYuMAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAeAAAAAgAAADMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQzxHgobEa4QAAAAAAAAAAAAAAAAAAAAA7AAMA/v8JAAYA
AAAAAAAA////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////AQD+/wMKAAD/////AAkCAAAAAADAAAAAAAAARhwA
AABNaWNyb3NvZnQgV29yZCA2LjAgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1
bWVudC42AAAAAAA7AAMA/v8JAAYAAAAAAAAAAAAAAAEAAAABAAAAAAD+/wAAAwoAAAAAAAAAAAAA
AAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAABoAgAADAAAAAcAAACYAAAACAAAANwAAAAM
AAAAAAEAAAsAAAAkAQAADQAAAEgBAAAPAAAAbAEAABAAAACQAQAACgAAALQBAAASAAAA2AEAAA4A
AAD8AQAACQAAACACAAATAAAARAIAAADBwQJgCWAJFADBwQK4C7gLGQDBwUCoDBAOGwDB2AEXAAMA
AAAAAAAAAAAAAAAAAB4AAAAuAAAARjpcTUFQUFNcTVNPRkZJQ0VcV0lOV09SRFxURU1QTEFURVxO
T1JNQUwuRE9UAAAAAAAAAAAAAAAAAAAAHgAAAAQAAABzc3MAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAQAAAAIY5WqncpWUAM8AJBAAAFABlAAAAAAAAAAAAAAAAAwAAFRkA
ADsjAAAAAAAAAAAAAAAAAAAAAAAAFRYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ACAAAGoAAAAAIAAAagAAAGogAAAAAAAAaiAAAAAAAABqIAAAAAAAAGogAAAAAAAAaiAAABQAAADE
IAAAAAAAAMQgAAAAAAAAxCAAAAAAAADEIAAAAAAAAMQgAAAAAAAAxCAAAAoAAADOIAAAEAAAAMQg
AAAAAAAAeSIAAFcAAADeIAAABAAAAOIgAAAAAAAA4iAAAAAAAADiIAAAAAAAAOIgAAAAAAAA4iAA
AAAAAADiIAAAAAAAAOIgAAAAAAAA/iAAAAIAAAAAIQAAAAAAAAAhAAAAAAAAACEAABoAAAAaIQAA
kAAAAKohAACQAAAAOiIAAB4AAADQIgAAVAAAACQjAAAXAAAAWCIAACEAAAAAAAAAAAAAAAAAAAAA
AAAAaiAAAAAAAADiIAAAAAAAAAAADQAOAAEAAgDiIAAAAAAAAOIgAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAOIgAAAAAAAA4iAAAAAAAABYIgAAAAAAAOIgAAAAAAAAaiAAAAAAAABqIAAAAAAAAOIgAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAN4gAAAAAAAA4iAAAAAAAADiIAAAAAAAAOIgAAAAAAAA4iAAAAAA
AABqIAAAAAAAAOIgAAAAAAAAaiAAAAAAAADiIAAAAAAAAP4gAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AH4gAAAaAAAAmCAAACwAAABqIAAAAAAAAGogAAAAAAAAaiAAAAAAAABqIAAAAAAAAOIgAAAAAAAA
/iAAAAAAAADiIAAAHAAAAOIgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABCYXJv
biBIZXhhIGlzIG9uZSBvZiBJbmRpYSdzIGxlYWRpbmcgTXVsdGltZWRpYSBTb2Z0d2FyZSBjb21w
YW55IGRldmVsb3BpbmcgY3VzdG9taXplZCBNdWx0aW1lZGlhIEFwcGxpY2F0aW9ucyBpbiB0aGUg
YXJlYSdzIG9mICBDb21wdXRlciBCYXNlZCBUcmFpbmluZyBTeXN0ZW1zICwgQ29ycG9yYXRlIENv
bW11bmljYXRpb25zICwgSW50ZXJhY3RpdmUgRWxlY3Ryb25pYyBDYXRhbG9ncyAoSUVUTSdzL0lQ
QydzIC0gTUlMIFNwZWNzIGRyaXZlbiksIFBvaW50IE9mIEluZm9ybWF0aW9uIFRlcm1pbmFscyBh
bmQgTXVsdGltZWRpYSBkYXRhYmFzZSBBcHBsaWNhdGlvbnMuDQ1CYXJvbiBIZXhhIHdhcyBmb3Vu
ZGVkIGluIFNlcHRlbWJlciA5MyBhbmQgaGFzIGJlZW4gcGlvbmVlcmluZyBNdWx0aW1lZGlhIHNp
bmNlIHRoZW4gaW4gSW5kaWEuIEl0IGlzIGFuICAgb3JnYW5pemF0aW9uICBmb3VuZGVkIGJ5IGVu
dHJlcHJlbmV1cnMgYW5kIGhvdXNlcyBvdmVyIDI1IHBlb3BsZS4gSXQgaXMgYSBCYW5nYWxvcmUg
YmFzZWQgY29tcGFueSBhbmQgaXMgaW4gdGhlIHByb2Nlc3Mgb2YgZXhwYW5kaW5nIGl0cyBidXNp
bmVzcyBhbGwgb3ZlciB0aGUgY291bnRyeSAuIEJhcm9uIEhleGEgaGFzIHRvIGl0cyBjcmVkaXQg
YSB2ZXJ5IGhpZ2ggcHJvZmlsZSBsaXN0IG9mIGN1c3RvbWVycyByYW5naW5nIGZyb20gRm9ydHVu
ZSA1MDAsIERlZmVuc2UgLCBHb3Zlcm5tZW50L1B1YmxpYyBTZWN0b3IgRW50ZXJwcmlzZSBhbmQg
Y29ycG9yYXRlcy4NDVNvbWUgb2YgdGhlIGN1c3RvbWVycyB0aGF0IEJhcm9uIEhleGEgaGFzIHdv
cmtlZCBmb3IgYXJlIGFzIGZvbGxvd3MgOg0NIA0qKiBJVEMgTHRkLg0qKiBCQVRFTENPICAoQmFo
cmFpbiBUZWxjb20pDSoqIFRoZSBOYWdhcmp1bmEgR3JvdXANKiogSUFUICggVVNBKQ0qKiBDb2F0
cyBJbmRpYSBMdGQuDSoqIENDU0wNKiogTWluaXN0cnkgb2YgRGVmZW5jZQ0qKiBIaW5kdXN0YW4g
QWVyb25hdXRpY3MgTGltaXRlZCAoIDMgRGl2aXNpb25zIG9mIEhBTCApDSoqIE5hdGlvbmFsIEFl
cm9uYXV0aWNhbCBMYWJvcmF0b3J5DSoqIENlbnRyZSBmb3IgQWVyb25hdXRpY2FsIFN5c3RlbXMs
IFN0dWRpZXMgYW5kICBBbmFseXNpcw0qKiBBZXJvbmF1dGljYWwgRGV2ZWxvcG1lbnQgRXN0YWJs
aXNobWVudA0qKiBBU0lFTw0qKiBBREENKiogVGhlIEdhbGx1cCBPcmdhbml6YXRpb24gDSoqIFdp
cHJvICBJbmZvdGVjaCANKiogS2lybG9za2FyICAgR3JvdXANKiogR3JpbmR3ZWxsIE5vcnRvbiBM
dGQNKiogM1NFIA0qKiBUYXRhIC0gSUJNICggVElTTCApDSoqIEdvdmVybm1lbnQgb2YgS2FybmF0
YWthDSoqIE1jRG93ZWxsICYgQ28uTHRkLiggVUIgR3JvdXApDSoqIEluZGlhbiBFeHByZXNzDSAN
DEJ1c2luZXNzIFBhcnRuZXJzIDoNIA1FZENJTCAtIEdvdnQub2YgSW5kaWEgT3JnYW5pemF0aW9u
IHVuZGVyIHRoZSBNaW5pc3RyeSBvZiBIUkQuIFRoZSBNT1Ugd2lsbCBiZSB0byBkZXZlbG9wIENC
VC9TTUkgaW4gSW5kaWEgYW5kIGluIG90aGVyIGNvdW50cmllcyBmb3IgR292ZXJubWVudCBkcml2
ZW4gbmVlZHMNDQ1DQ1NMIC0gQ2FuYmFuayBDb21wdXRlciBTZXJ2aWNlcyBMdGQuICggIEEgY29u
c29ydGl1bSBvZiBzaXggbmF0aW9uYWxpemVkIEluZGlhbiBCYW5rcykNDVRoZSBNT1UgYWxsb3dz
IGJvdGggdGhlIG9yZ2FuaXphdGlvbnMgdG8gbGV2ZXJhZ2UgdGhlIHN0cmVuZ3RocyBvZiB0aGUg
cGFydG5lciBhbmQgZGV2ZWxvcCAgQ0JUL1NNSSBwcm9kdWN0cyBhbmQgY3VzdG9taXplZCBzZXJ2
aWNlcyBmb3IgRmluYW5jZS9CYW5raW5nL0luc3VyYW5jZSBpbiBJbmRpYS4NDQ1BICBCcmllZiAg
cHJvZmlsZSBvZiBvdXIgcGVvcGxlOg0NQ0VPknMgYmFja2dyb3VuZDogIA0NR2VyYXJkIEouIFJl
Z28gaXMgdGhlIGNvLWZvdW5kZXIgYW5kIENFTyBvZiBCYXJvbiBIZXhhIFB2dC4gTHRkLiwgd2hp
Y2ggaXMgb25lIG9mIHRoZSBwaW9uZWVyaW5nIGFuZCBsZWFkaW5nIE11bHRpbWVkaWEgc29mdHdh
cmUgY29tcGFuaWVzIGluIEluZGlhLiBXaXRoIGEgYmFja2dyb3VuZCBpbiBJVCwgTXVsdGltZWRp
YSAoc2luY2UgOTIpLCBBSSBhbmQgRXhwZXJ0IFN5c3RlbXMgYW5kIE1hbmFnZW1lbnQsIGhpcyBh
cmVhcyBvZiBpbnRlcmVzdCBhbmQgcmVzZWFyY2ggYXJlIGluIHRoZSBhcmVhcyBvZiBGdXR1cmUg
VGhpbmtpbmcsIEluZGlhbiBkZXZlbG9wbWVudCwgUHJvZ3Jlc3MsIENoYW5nZSwgQXBwbGljYXRp
b24gb2YgTmF0dXJhbCBsaWZlIHRvIFN5c3RlbXMgRW5naW5lZXJpbmcsIENyZWF0aXZpdHkgaW4g
b3JnYW5pemF0aW9ucyBhbmQgRW52aXJvbm1lbnRzLCBXb21lbiBpbiBTb2NpZXR5LCBJbmRpYW4g
U29jaW9lY29ub21pYyBkZXZlbG9wbWVudCwgRWR1Y2F0aW9uYWwgTWV0aG9kb2xvZ2llcyBhbmQg
UmVzZWFyY2gsIEVkdWNhdGlvbmFsIHRvb2xzIGFuZCBUZWNobm9sb2dpZXMsIEdJSS9OSUkgKEds
b2JhbC9OYXRpb25hbCBJbmZvcm1hdGlvbiBJbmZyYXN0cnVjdHVyZSkgSW5mb3JtYXRpb24gRW52
aXJvbm1lbnRzLCBJbmZvcm1hdGlvbiBUZWNobm9sb2dpZXMsIENvbW11bmljYXRpb24gdGVjaG5v
bG9naWVzLCAgVmlydHVhbCByZWFsaXR5LCBFbWVyZ2luZyBUZWNobm9sb2dpZXMsIFRlbGVjb21t
dW5pY2F0aW9ucywgTWFjaGluZSBzeXN0ZW1zIGFuZCBSb2JvdGljcywgTWFudWZhY3R1cmluZyBz
eXN0ZW1zLCBSaWdodHMsIFByaXZhY3kgYW5kIEZyZWVkb20gb2YgSW5mb3JtYXRpb24sIFBvbGlj
eSAtIERldmVsb3BtZW50LCBBcHBsaWNhdGlvbiwgUmVzZWFyY2gsIFBzeWNob2xvZ3kgYW5kIEh1
bWFuIEJlaGF2aW9yLCBSb2xlIG9mIFBlb3BsZSBpbiBFbnZpcm9ubWVudHMgLSBQcml2YXRlLCBC
dXNpbmVzcywgR292ZXJubWVudCBhbmQgU29jaWV0eSwgIEludGVyYWN0aXZlIExlYXJuaW5nIFN5
c3RlbXMsIEltYWdpbmcgVGVjaG5vbG9neSwgQmlvbG9naWNhbCBTeXN0ZW1zLCBFbmdpbmVlcmlu
ZywgV29ya2Zsb3cgU3lzdGVtcywgVGVsZWNvbW11bmljYXRpb24gc3lzdGVtcywgVGVsZS1FbnZp
cm9ubWVudHMsIEluZm9ybWF0aW9uIFdhcmZhcmUgLSBCb3RoIEVjb25vbWljIGFuZCBNaWxpdGFy
eSwgQnVzaW5lc3MgYW5kIEZ1dHVyZSBUZWNobm9sb2dpZXMsIE5hdGlvbmFsIFNlY3VyaXR5IGlz
c3VlcywgTWlsaXRhcnkgU3RyYXRlZ3kvRG9jdHJpbmUgYW5kIFdhcmZhcmUsIFdlYXBvbnMgRGVz
aWduLCBFY29ub21pYyBEZXZlbG9wbWVudCwgRkRJLCBFbWVyZ2luZyBFY29ub215IFJlc2VhcmNo
LCBDb21wZXRpdGl2ZSBFY29ub21pYyBhbmQgQnVzaW5lc3MgUmVzZWFyY2gsIEFuaW1hbCBCZWhh
dmlvciwgQ29tbXVuaWNhdGlvDgAPAAgAAQBLAA8AAAAEABoAAEDx/wIAGgAGTm9ybWFsAAIAAAAD
AGEJBAAAAAAAAAAAAAAAAAAAAAAAAAAiAEFA8v+hACIAFkRlZmF1bHQgUGFyYWdyYXBoIEZvbnQA
AAAAAAAAAAAAAAAAAAAVFgAABQD/////BQD/////BAAEIP//AQAAIP//AgAEIP//AwAAIP//BAAA
AAAAXQUAALkNAAD+FAAAFRYAAAAAFAAAAAEA8AIAAAIAFQEAAAMAAAAAAAADAAAVGQAADQAAAwAA
qRMAABUZAAAOAA8AFRYAABwAA3NzcxVDOlxHRVJBUkRcQ09QUkZMMi5ET0P/QEVwc29uIExYLTgw
MABMUFQxOgBFUFNPTjkARXBzb24gTFgtODAwAAAAAAAAAAAAAAAAAAAAAAAAAAAKAwwDRABMAANm
AAABAAEA/gD+AFmBAQAIAHgAAQABAJAAAQD6AnKAAQBWuQIArasZAAAAGQAAAAAAAgBkAAIAAAAA
AAAA//9NNwAARgyqBx0AAQAAAP//AAD//wAA/////wAAAAAAAP//////////RXBzb24gTFgtODAw
AAAAAAAAAAAAAAAAAAAAAAAAAAAKAwwDRABMAANmAAABAAEA/gD+AFmBAQAIAHgAAQABAJAAAQD6
AnKAAQBWuQIArasZAAAAGQAAAAAAAgBkAAIAAAAAAAAA//9NNwAARgyqBx0AAQAAAP//AAD//wAA
/////wAAAAAAAP//////////A4ABAPUCAAD1AgAACQAAgAAA9QIAAAAAAAD1AgAAAhwAAAAAAAAA
FBYAABUWAAAABQADAAAAAAAFFBkAAAAAVwAVFpABAABUaW1lcyBOZXcgUm9tYW4ADBaQAQIAU3lt
Ym9sAAsmkAEAAEFyaWFsABE1kAEAAENvdXJpZXIgTmV3ABMikAEAAE1TIFNhbnMgU2VyaWYAAAAE
AAEACAAAANACAAAAAAAAAAAAAAAAwqMThgAAAAADAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAACQDFwAAAAAAAAAAA3NzcwAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAA==
------ =_NextPart_000_01BC4AB9.B4B69100--
Received: from cnri by ietf.org id aa16686; 16 Apr 97 15:45 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20397;
16 Apr 97 15:45 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <RAA02603 at pad-thai.cam.ov.com>; Wed, 16 Apr 1997 17:51:24 GMT
Message-Id: <199704161751.NAA28737 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: minutes at ietf.org
Cc: linn at cam.ov.com, cat-ietf at mit.edu
Subject: Minutes from Memphis CAT-WG meeting
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 16 Apr 1997 13:51:14 -0400
From: John Linn <linn at cam.ov.com>
Precedence: bulk
CAT-WG MINUTES FOR MEMPHIS MEETING
Revised draft, 14 April 1997
Minutes compiled by John Linn (OpenVision)
QUICK SUMMARY
The Common Authentication Technology (CAT) WG met for a single session
at the Memphis IETF. Several Internet-Drafts regarding extension
proposals to Kerberos protocol (Public-Key Utilizing Tickets for
Application Servers (PKTAPP), Public-Key Cryptography for Initial
Authentication in Kerberos (PKINIT), Public-Key Cryptography for
Cross-Realm Authentication in Kerberos (PKCROSS), Kerberos Change
Password Protocol (CHG-PASSWORD), and Integrity Protection for the
Kerberos Error Message (KERBEROS-ERR-MSG)) were presented and
discussed. Discussions were initiated on work to enable Kerberos
operation in firewall environments.
Status of the FTP Security draft (ftpsec-09), currently in IETF
Last-Call and therefore under IESG jurisdiction, was reviewed.
Ongoing progress was reported in defining a facility for protecting
the Simple GSS-API Negotiation Mechanism (SNEGO)'s negotiation
facility; it is anticipated that this facility, along with responses
to other SNEGO comments, will be incorporated within a revised SNEGO
draft to be issued within the next few weeks and subsequently placed
into WG Last-Call targeting advancement to Proposed Standard. An
initial Internet-Draft revising RFC-1510 (Kerberos protocol) is
anticipated this week; it is intended that a successor version to be
published a few weeks later will comprise the basis for advancement to
Draft Standard. A revised version of the Independent Data Unit
Protection (IDUP) draft was presented and discussed; a subsequent
version responding to comments, and an associated IDUP C bindings
draft, is anticipated in the next few weeks. Limited discussion of
the GSS-V2 C bindings draft was undertaken; it is intended that a
draft memo describing the alignments and corrections required to
RFC-2078 be distributed to the mailing list by the first half of May.
GENERAL DISCUSSION
The list of active CAT-relevant Internet-Drafts was reviewed. Denis
Pinkas (Bull) stated that no comments had been received from the WG on
the XGSS and SESAME mechanism drafts, and reiterated a solicitation
for their discussion. The XGSS draft was recently reissued to renew
its currency at the I-D repository, but its content has not changed.
KERBEROS EXTENSIONS: PKTAPP
Ari Medvinsky (CyberSafe) gave a presentation on the new PKTAPP draft:
approximately 4 attendees indicated that they had reviewed this
document. Indicated motivations for PKTAPP: create within a single
Kerberos extension an authentication solution combining public-key and
Kerberos technologies, integrate Sirbu and Chuang's (CMU) PKDA
concepts, and leverage PKINIT. Ari stated that PKTAPP enables
interoperability between public-key and Kerberos infrastructures,
using public-key certificates as the basis for Kerberos TGT
acquisition. He also stated that PKDA performs public-key
client-server authentication without a KDC, while retaining advantages
associated with use of Kerberos tickets (e.g., short-lived
credentials).
Ari identified the following issues re PKTAPP:
- Use a local KDC (per machine) or instead modify application
services? Ari recommended an approach which doesn't require modifying
applications. Some discussion about delegation options and
alternatives ensued.
- Naming approach: X.500 vs. Kerberos? Ari recommended that X.500
names be used.
- API: should PKTAPP be supported under GSS-API or not? Ari was
neutral.
Denis Pinkas asked how a PKTAPP/PKDA approach would compare to SPKM.
Ari disclaimed detailed familiarity with SPKM, but referenced SSL/TLS
by comparison. PKTAPP enables multiple secret-key contexts to be
established with a single public-key operation, but otherwise it was
believed (at a coarse level) that the approaches were similar.
KERBEROS EXTENSIONS: PKINIT AND PKCROSS
Brian Tung (ISI) led discussion on the PKINIT and PKCROSS I-Ds.
Regarding PKINIT, approximately 10 attendees indicated that they had
been reviewing the drafts. In the latest version, the KDC recovery
feature has been removed for lack of indicated interest. A reference
implementation is available: see
http://gost.isi.edu/info/kerberos/distribution.html. Brian's issues
list (available at http://gost.isi.edu/brian/security/pk_init.html,
and posted to the CAT mailing list) identifies items which he believes
need to be resolved prior to WG Last-Call. An attendee commented that
it might be necessary to accomodate TCP support, not now present, in
order to carry large-sized certificate chains; this was accepted as an
issue. An additional issue, regarding addition of CAs to the
transited field, had previously been raised on the CAT list and was
reiterated for consideration. Denis Pinkas observed that the current
draft's treatment of signature keys represented improvement relative
to its predecessor, but requested additional changes; Bill Sommerfeld
(HP) noted his perception that the residual dispute might be
unreconcialiable to the satisfaction of all interested parties.
Approximately 8 attendees indicated that they had been reviewing
PKCROSS drafts. The current draft incorporates a new scheme for
ticket-based key distribution, with relevant information cached in
profiles for efficiency, and an added mechanism for determining trust.
Information is available at
http://gost.isi.edu/brian/security/pk_cross.html; as with PKINIT, the
PKCROSS issues list has been posted to the CAT list to solicit
discussion.
KERBEROS EXTENSIONS: CHG-PASSWORD
Marc Horowitz (Cygnus) spoke briefly on the CHG-PASSWORD draft which
he had submitted; approximately 6 attendees indicated familiarity with
this draft. He stated that implementation work is underway at Cygnus,
and that the result could likely be donated into the MIT code
base. Ted Ts'o (MIT) noted that another, earlier proposal with similar
functionality has been implemented in Xyplex terminal servers and is
supported in MIT's Kerberos V5 release 1.0, though is not currently
documented in I-D form; it was believed that the particulars of Marc's
proposal were simpler than those of the earlier proposal, but Ted
offered to circulate that earlier proposal as an I-D following the
meeting, in order that the alternatives can be compared within the WG
to determine their relative merits.
KERBEROS EXTENSIONS: KERBEROS-ERR-MSG
Matt Hur (CyberSafe) led discussion on the KERBEROS-ERR-MSG I-D.
Given that the error structure as defined in RFC-1510 has no checksum
field, the proposed approach is to place a checksum in an e-data type
field, thereby providing a code-independent means to return
integrity-protected error data; the approach is intended to be
compatible with existing Kerberos implementations. Reserved type
field value ranges are required to avoid collision with
preauthentication data type values. The format of the
error-representing structure is ASN.1/DER encoded. Bill Sommerfeld
observed that extra, trailing fields can be added compatibly to ASN.1
objects through use of explicit tagging, and asserted that this type
of approach would be cleaner. The rationale for providing the err-msg
scheme was described as enabling a client to determine whether or not
to believe an error message (e.g., "password invalid"), but several
attendees questioned the need for such a facility.
KERBEROS AND FIREWALLS
Bill Sommerfeld spoke briefly to solicit follow-up list discussion on
Kerberos usage in firewall environments. Identified issues include:
relaying requests, addresses in tickets, location of relays, multi-hop
support, and Kerberos over TCP (described as "part of the solution,
not all of it".) Cliff Neuman noted that the IANA has assigned both
TCP and UDP ports for Kerberos.
FTP SECURITY
FTP Security (ftpsec-09) is in IETF Last-Call and therefore under IESG
jurisdiction. Implementor organizations represented at the meeting
included Trusted Information Systems, Cygnus, and Spyrus. Marc
Horowitz reported that simple changes are being made to enable use of
TLS as a facility to protect FTP. Per direction received from the
Security AD, a revised I-D reflecting changes and comments is to be
submitted.
NEGOTIATION MECHANISM
Negotiation mechanism issues and proposals have been the subject of
active discussion on the CAT mailing list during recent weeks. Denis
Pinkas summarized the current situation. The current snego-03 draft
includes optimistic negotiation, based on a contribution submitted by
Peter Brundrett (Microsoft), which avoids the need for an extra round
trip to accomplish negotiated context establishment when the
initiator's preferred mechanism is accepted by a context's target.
The current proposal works well in selecting among comparably-strong
mechanisms, but is vulnerable to rollback attacks forcing selection of
a weaker alternative if mechanisms of varying strengths are supported
and proposed.
Bill Sommerfeld presented the results of a recent side discussion
involving WG members interested in negotiation and its protection,
which yielded an approach for protecting negotiation within the SNEGO
framework. In this approach, all tokens in a context establishment
sequence are encapsulated; the final token includes (assuming that a
MIC-capable mechanism is selected) a MIC computed on selection
elements. Bill Sommerfeld is to provide, within the IETF week, text
to Denis defining the draft protection enhancement; the result is
planned for inclusion in another SNEGO draft in the next few weeks, to
be placed subsequently into WG Last-Call targeting advancement to
Proposed Standard. Marc Horowitz, who had offered an alternate
protected negotiation proposal to the WG, indicated his willingness to
accept a protection-enhanced version of SNEGO as the WG's approach.
FOLLOW-UP PLANS FOR CURRENT RFCs
Cliff Neuman (ISI) spoke on the current status of the successor
document to RFC-1510 (RFC-1510bis). He intends to produce a first
successor draft within the IETF week, and solicited any added comments
needing to be included. A successor draft is intended within several
weeks, and to be targeted for advancement to Draft Standard;
incompatible protocol changes are not planned, and it is intended that
RFC-1510bis will not inconvenience the existing installed Kerberos
base. A preliminary summary of issues to be handled was sent to the
mailing list and presented at the meeting. Cliff intends to clarify
that possession of a ticket doesn't confer authorization, given the
recognition that different KDCs might apply different (or no)
authorization policies. He noted the fact that several Kerberos
extension I-D's exist, and that additional extension work has been
undertaken outside the IETF; he intends to add material about how such
extensions could be used, but not to incorporate them within the
standards track specification. MIT-accumulated errata and
newly-defined triple-DES e-types will be included. Issues identified
for list discussion, and possibly to be included in the successor I-D,
include transited field processing and error message integrity.
Regarding RFC-1964, it was observed that definition of new encryption
types would likely be appropriate in order to support triple-DES. It
was considered that this should be addressed most appropriately once
RFC-1510bis is stable.
IDUP
Carlisle Adams (Entrust) led discussion on the current idup-07 draft.
Approximately 5 attendees indicated that they had reviewed the
draft. Comments had been received on the mailing list from John Wray
(Digital), but have not yet been addressed in this version. Changes in
idup-07 include a new idup_acquire_cred_with_auth() call with an
additional "authenticator" parameter carrying a password or PIN;
Carlisle described this call as non-mandatory, and stated that it was
added upon request of an IDUP consumer. New cred_usage values were
added. New evidence-related calls were added, per requests from Denis
Pinkas. Various wording changes were made in response to comments
from several reviewers, and changes were made to protection options.
IDUP's SE and EV calls are intended to be easier for calling
applications to employ when straightforward tasks are to be performed;
more general calls within the specification are considered necessary
in order to satisfy more complex application requirements. Within the
next couple of months, Carlisle intends to submit another IDUP draft
(responsive to John Wray's comments) and a corresponding IDUP C
bindings specification.
In closing discussion, Bengt Ackzell suggested addition of a new call
(GSS_List_internal_names()) which would enumerate multiple names
associated with a given context. When considered, this appeared more
applicable to IDUP than to base GSS; it may be discussed further on
the mailing list as a candidate IDUP facility.
GSS-V2 / C BINDINGS
Limited discussion of the GSS-V2 C bindings draft was undertaken;
approximately 4 attendees indicated that they had reviewed this most
recent version. John Linn suggested that all individuals concerned
with the areas changed in the cbind-04 draft should validate that
those changes are suitable and satisfactory; he intends to distribute
a draft memo describing the alignments and corrections required to
RFC-2078, and related issues, to the mailing list by the first half of
May.
Received: from ietf.org by ietf.org id aa21899; 16 Apr 97 17:38 EDT
Received: from nacho.cisco.com by ietf.org id aa21422; 16 Apr 97 17:29 EDT
Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id OAA26889; Wed, 16 Apr 1997 14:26:13 -0700
Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id OAA05358; Wed, 16 Apr 1997 14:26:11 -0700
X-Sender: fred at stilton.cisco.com
Message-Id: <v03007822af7aeef7b59d at [171.69.128.118]>
In-Reply-To: <970416162604.15992 at mail07.mitre.org.0>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 16 Apr 1997 14:11:06 -0700
To: "John C. C. White" <jccw at mail07.mitre.org>
Sender:ietf-request at ietf.org
From: Fred Baker <fred at cisco.com>
Subject: Re: Internet-draft for NETBLT
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 4:26 PM -0400 4/16/97, John C. C. White wrote:
>My preference would be that it become an experimental standard. I'm concerned
>about the number of potential snags in the standards process, but if there
>are
>reasonable prospects for making it through the process, that's the way to go.
My guess is that getting it to Experimental is not too much of an issue. I
haven't yet read the draft, but I will include our standard list of "please
consider this and make sure there is appropriate text in the document."
The document needs to address security and management, at least to the
extent of making a significant attempt at enumerating the threats to which
the protocol is subject and how they are addressed, and enumerating the
variables and their recommended settings or describing how decide what to
set them to. As an IETF standards track document, you give up change
control, which would not be true if you went informational. One should be
able to implement the protocol from a combination of the document and the
documents it references, and the referenced documents should be readily
available to anyone who chooses to implement. And the technical meaning of
"experimental" is that the IETF does not recommend that people implement
the protocol - those involved in the experiment should implement it, and
others should confer with the experimenters before doing so, as the
specification may have migrated without being documented.
If you're comfortable with that, and those concerns are met, I think we
should be able to accommodate you after reviewing the document. The thing
to do is advise the Transport Area Directors (copying Steve Coya) that you
would like to take it to Experimental, so that they can start the last call
process on the IETF list.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"I don't want parole. I'm too busy working on my web site."
Charles Manson, 3-27-97 at his parole hearing.
Received: from ietf.org by ietf.org id aa24426; 16 Apr 97 18:12 EDT
Received: from nacho.cisco.com by ietf.org id aa24332; 16 Apr 97 18:10 EDT
Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id PAA29529 for <ietf at ietf.org>; Wed, 16 Apr 1997 15:07:12 -0700
Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id PAA05377 for <ietf at ietf.org>; Wed, 16 Apr 1997 15:07:10 -0700
X-Sender: fred at stilton.cisco.com
Message-Id: <v03007826af7afd9725d4 at [171.69.128.118]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 16 Apr 1997 15:07:08 -0700
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Fred Baker <fred at cisco.com>
Subject: apologies
Source-Info: From (or Sender) name not authenticated.
My previous note was intended to copy the IESG, not the IETF. You'll
forgive me, I trust.
That said, you can take the comments as illustrative of discussions we have
with document authors, and what you might receive from us in a similar
occurrence.
Received: from ietf.org by ietf.org id aa02207; 16 Apr 97 21:10 EDT
Received: from ng.netgate.net by ietf.org id aa02046; 16 Apr 97 21:05 EDT
Received: from [205.214.160.88] (d97.netgate.net [205.214.160.135])
by ng.netgate.net (8.8.5/8.8.5) with ESMTP id SAA08584;
Wed, 16 Apr 1997 18:09:28 -0700 (PDT)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v03102811af7a699d46c6 at [205.214.160.117]>
In-Reply-To: <199704161017.MAA02294 at x0.ripe.net>
References: Your message of "Tue, 15 Apr 1997 19:05:36 EST."
<9703158611.AA861157240 at ncr.disa.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 16 Apr 1997 04:36:34 -0700
To: Geert Jan de Groot <GeertJan.deGroot at ripe.net>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re: Hotel space in Munich
Cc: Bill Flanigan <flanigab at ncr.disa.mil>, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 3:17 AM -0700 4/16/97, Geert Jan de Groot wrote:
>I don't think this is fair to complain about.
>For the last thirty-and-some IETF's that were held in the USA,
>no IETF group air fares were available for international flights,
>so the foreign attendees had to take the full charge.
(we won't quibble about the recent, two IETF meetings held in
Europe. For the most part, yes, North America has been the venue.)
One of the reasons for holding the meetings elsewhere is to
sensitize us all to various issues. Though not part of a list that a
US-based participant might have generated, finding out about group airfares
as an issue strikes me as important and appropriate. On the other hand,
insufficient room blocking has become a chronic problem. My own opinion is
that a lack of arrangements for, or listing of, lower-rate accomodations
is, too, but the community has generally not responded to efforts at
raising this concern.
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from ietf.org by ietf.org id aa01245; 17 Apr 97 10:02 EDT
Received: from ietf.ietf.org by ietf.org id aa00440; 17 Apr 97 9:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: ietf-otp at bellcore.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-otp-ext-02.txt
Date: Thu, 17 Apr 1997 09:55:27 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704170955.aa00440 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 One Time Password
Authentication Working Group of the IETF.
Title : OTP Extended Responses
Author(s) : C. Metz
Filename : draft-ietf-otp-ext-02.txt
Pages : 8
Date : 04/16/1997
This document provides a specification for a type of response to an OTP
[RFC 1938] challenge that carries explicit indication of the response's
encoding. Codings for the two mandatory OTP data formats using this new
type of response are presented.
This document also provides a specification for a response that allows
OTP generator to request that a server re-initialize a sequence and
change parameters such as the secret pass phrase.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-otp-ext-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-otp-ext-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-otp-ext-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: <19970416134820.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-otp-ext-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-otp-ext-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970416134820.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01819; 17 Apr 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa00500; 17 Apr 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-yergeau-utf8-rev-00.txt
Date: Thu, 17 Apr 1997 09:55:40 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704170955.aa00500 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : UTF-8, a transformation format of Unicode and ISO 10646
Author(s) : F. Yergeau
Filename : draft-yergeau-utf8-rev-00.txt
Pages : 8
Date : 04/16/1997
ISO/IEC 10646-1 and the Unicode Standard jointly define a multi-octet
character set which encompasses most of the world's writing systems.
Multi-octet characters, however, are not compatible with many current
applications and protocols, and this has led to the development of a few
so-called UCS transformation formats (UTF), each with different
characteristics. UTF-8, the object of this memo, has the characteristic of
preserving the full US-ASCII range, providing compatibility with file
systems, parsers and other software that rely on US-ASCII values but are
transparent to other values. This memo updates and replaces RFC 2044, in
particular addressing the question of versions of the relevant standards.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-yergeau-utf8-rev-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-yergeau-utf8-rev-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-yergeau-utf8-rev-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: <19970416140456.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-yergeau-utf8-rev-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-yergeau-utf8-rev-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970416140456.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01820; 17 Apr 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa00581; 17 Apr 97 9:56 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-benoit-00.txt
Date: Thu, 17 Apr 1997 09:56:07 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704170956.aa00581 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Loop-free Interswitch Message Path (LSMP) Protocol
Author(s) : K. Dobbins, J. Benoit, T. Grant, D. Ruffen
Filename : draft-rfced-info-benoit-00.txt
Pages : 8
Date : 04/16/1997
The Loop-Free Interswitch Message Path (LSMP) protocol is part of the
InterSwitch Message Protocol (ISMP). ISMP was designed to facilitate
interswitch communication within distributed connection-oriented switching
networks. The LSMP protocol is used to create and maintain the flood path
over which undirected ISMP messages are sent.
Internet-Drafts are available by anonymous FTP. 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-benoit-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-benoit-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-benoit-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: <19970416162054.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-benoit-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-benoit-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970416162054.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01805; 17 Apr 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa00345; 17 Apr 97 9:55 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-00.txt
Date: Thu, 17 Apr 1997 09:55:12 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704170955.aa00345 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internetworking Over NBMA
Working Group of the IETF.
Title : A Distributed NHRP Service Using SCSP
Author(s) : J. Luciani
Filename : draft-ietf-ion-scsp-nhrp-00.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-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-scsp-nhrp-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-ion-scsp-nhrp-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: <19970416110610.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-scsp-nhrp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-scsp-nhrp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970416110610.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01807; 17 Apr 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa00301; 17 Apr 97 9:55 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-01.txt
Date: Thu, 17 Apr 1997 09:55:07 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704170955.aa00301 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 : Server Cache Synchronization Protocol (SCSP)
Author(s) : J. Luciani, G. Armitage, J. Halpern
Filename : draft-ietf-ion-scsp-01.txt
Pages : 35
Date : 04/16/1997
This document describes the Server Cache Synchronization Protocol (SCSP)
and is written in terms of SCSP's use within Non Broadcast Multiple Access
(NBMA) networks; although, a somewhat straight forward usage is applicable
to BMA networks. SCSP attempts to solve the generalized cache
synchronization/cache-replication problem for distributed protocol
entities. However, in this document, SCSP is couched in terms of the
client/server paradigm in which distributed server entities, which are
bound to a Server Group (SG) through some means, wish to synchronize the
contents (or a portion thereof) of their caches which contain information
about the state of clients being served.
Internet-Drafts are available by anonymous FTP. 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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-scsp-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-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: <19970416110325.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-scsp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-scsp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970416110325.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01822; 17 Apr 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa00730; 17 Apr 97 9:56 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-sorting-00.txt
Date: Thu, 17 Apr 1997 09:56:47 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704170956.aa00730 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 : LDAP Control Extension for Server Side Sorting
of Search Results
Author(s) : A. Herron, T. Howes, M. Wahl
Filename : draft-ietf-asid-ldapv3-sorting-00.txt
Pages : 5
Date : 04/17/1997
This document describes two LDAPv3 control extensions for server side
sorting of search results. These controls allows a client to specify the
attribute types and matching rules a server should use when returning the
results to an LDAP search request. The controls may be useful when the
LDAP client has limited functionality or for some other reason cannot sort
the results but still needs them sorted. Other permissible controls on
search operations are not defined in this extension.
The sort controls allow a server to return a result code for the sorting
of the results that is independent of the result code returned
for the search 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-sorting-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3-sorting-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-sorting-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: <19970417093336.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldapv3-sorting-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldapv3-sorting-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970417093336.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01818; 17 Apr 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa00623; 17 Apr 97 9:56 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-00.txt
Date: Thu, 17 Apr 1997 09:56:15 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704170956.aa00623 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Network Security For Large Trade Shows
Author(s) : A. Gwinn
Filename : draft-rfced-info-gwinn-00.txt
Pages : 8
Date : 04/16/1997
This document is designed to assist vendors and other participants in large
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 just 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) a vendor's demonstrations inoperable--quite
possibly for the entire show!
This dcoument 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. Vendors are
encouraged 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-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-gwinn-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-gwinn-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: <19970416165139.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-gwinn-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-gwinn-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970416165139.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01815; 17 Apr 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa00389; 17 Apr 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-thayer-cipher-01.txt
Date: Thu, 17 Apr 1997 09:55:17 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704170955.aa00389 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Stream Cipher Encryption Algorithm
Author(s) : R. Thayer
Filename : draft-thayer-cipher-01.txt
Pages : 9
Date : 04/16/1997
There is a need in the Internet community for an encryption algorithm that
provides interoperable operation with existing deployed commercial
cryptographic applications. This interoperability will allow for a
smoother transition to protocols that have been developed through the IETF
standards process. This document describes an existing algorithm that
satisifies this requirement.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-thayer-cipher-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-thayer-cipher-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-thayer-cipher-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: <19970416110854.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-thayer-cipher-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-thayer-cipher-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970416110854.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01816; 17 Apr 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa00451; 17 Apr 97 9:55 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-atm2-09.txt
Date: Thu, 17 Apr 1997 09:55:34 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704170955.aa00451 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the AToM MIB Working Group of
the IETF.
Title : Definitions of Supplemental Managed Objects for ATM
Management
Author(s) : F. Ly, M. Noto, A. Smith, K. Tesink
Filename : draft-ietf-atommib-atm2-09.txt
Pages : 99
Date : 04/16/1997
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-atommib-atm2-09.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-atm2-09.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-atommib-atm2-09.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970416135956.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-atommib-atm2-09.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-atommib-atm2-09.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970416135956.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01817; 17 Apr 97 10:04 EDT
Received: from ietf.ietf.org by ietf.org id aa00671; 17 Apr 97 9:56 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce at ietf.org
cc: cat-ietf at mit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-cat-idup-cbind-03.txt
Date: Thu, 17 Apr 1997 09:56:26 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704170956.aa00671 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Common Authentication
Technology Working Group of the IETF.
Title : Independent Data Unit Protection Generic Security
Service Application Program Interface: C-bindings
Author(s) : S. Klump, D. Thakkar
Filename : draft-ietf-cat-idup-cbind-03.txt
Pages : 149
Date : 04/16/1997
The Independent Data Unit Protection Generic Security Service Application
Program Interface (IDUP-GSS-API) extends the GSS-API [RFC-1508] for
applications requiring protection of a generic data unit (such as a file or
message) in a way that is independent of the protection of any other data
unit and independent of any concurrent contact with designated "receivers"
of the data unit. Thus, it is suitable for applications such as secure
electronic mail where data needs to be protected without any on-line
connection with the intended recipient(s) of that data. The protection
offered by the IDUP includes data origin authentication with data
integrity, data confidentiality with data integrity, and support for
non-repudiation services. Subsequent to being protected, the independent
data unit can be transferred to the recipient(s) - or to an archive -
perhaps to be processed ("unprotected") only days or years later.
The Independent Data Unit Protection Generic Security Service Application
Program Interface for Signing and Encrypting (IDUP-SE) provides a
simplified API for the services of signing and encrypting.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-cat-idup-cbind-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-idup-cbind-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-cat-idup-cbind-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: <19970416171231.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-cat-idup-cbind-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-idup-cbind-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970416171231.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02322; 17 Apr 97 10:07 EDT
Received: from ietf.ietf.org by ietf.org id aa00549; 17 Apr 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-nis-schema-00.txt
Date: Thu, 17 Apr 1997 09:55:48 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704170955.aa00549 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 : An Approach for Using LDAP as a Network Information
Service
Author(s) : L. Howard
Filename : draft-ietf-asid-nis-schema-00.txt
Pages : 19
Date : 04/16/1997
This document describes an experimental mechanism for mapping POSIX [13]
and TCP/IP network-related entities into X.500 entries so that they may be
resolved with the Lightweight Directory Access Protocol [1]. A set of
attribute types and object classes are proposed, along with specific
guidelines for interpreting them.
The intention is to assist the deployment of LDAP as an organizational
nameservice. No proposed solutions are intended as standards for the
Internet. Rather, it is hoped that a general consensus will emerge as to
the appropriate solution to such problems, leading eventually to the
adoption of standards. The proposed mechanism has already been implemented
with some success.
Internet-Drafts are available by anonymous FTP. 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-nis-schema-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-nis-schema-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-nis-schema-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: <19970416142612.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-nis-schema-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-nis-schema-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970416142612.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03800; 17 Apr 97 10:26 EDT
Received: from ietf.ietf.org by ietf.org id aa03689; 17 Apr 97 10:24 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-protocol-17.txt
Date: Thu, 17 Apr 1997 10:24:33 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704171024.aa03689 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.
Note: This revision reflects comments received during the last call period.
Title : Service Location Protocol
Author(s) : J. Veizades, E. Guttman, C. Perkins, S. Kaplan
Filename : draft-ietf-svrloc-protocol-17.txt
Pages : 72
Date : 04/16/1997
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 is especially
important as computers become more portable, and users less tolerant or
able to fulfill the demands of network system administration.
Internet-Drafts are available by anonymous FTP. 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-protocol-17.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-protocol-17.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-protocol-17.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" 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: <19970416134339.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-svrloc-protocol-17.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-svrloc-protocol-17.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970416134339.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13357; 17 Apr 97 12:01 EDT
Received: from ecrc.de by ietf.org id aa12959; 17 Apr 97 11:59 EDT
Received: from scorpio.ecrc.de (scorpio.ecrc.de [141.1.4.100]) by ecrc.ecrc.de (8.8.3/8.8.3/$Revision: 1.2 $) with ESMTP id RAA26005; Thu, 17 Apr 1997 17:55:07 +0200 (MET DST)
Received: from acrab25.ecrc.de (acrab25.ecrc.de [141.1.6.125])
by scorpio.ecrc.de (8.8.3/8.8.4/$Revision: 1.4 $) with ESMTP
id RAA06976; Thu, 17 Apr 1997 17:55:06 +0200 (MET DST)
Sender:ietf-request at ietf.org
From: Dave Morton <Dave.Morton at ecrc.de>
Received: (from dave at localhost) by acrab25.ecrc.de (8.8.2/8.8.2/$Revision: 1.1 $) id RAA15038; Thu, 17 Apr 1997 17:55:03 +0200 (MET DST)
Date: Thu, 17 Apr 1997 17:55:03 +0200 (MET DST)
Message-Id: <199704171555.RAA15038 at acrab25.ecrc.de>
To: craig at aland.bbn.com, schulzrinne at cs.columbia.edu
Subject: Re: Munich on Sunday
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
>Craig Partridge wrote:
>>
>> Question for our Munich hosts which is likely to be of interest to
>> anyone going to Munich.
>>
>> I haven't been in Germany for a while. Is it still the case that many
>> museums, restaurants, etc., shut down on Sundays? (My rule in Germany was
>> that Sunday was a good day for hiking -- and there's great hiking around
>> Munich).
>
>Not Sunday. Typical closing day for museums and some restaurants is
>Monday or Tuesday. However, stores won't be open on Sunday, with rare
>exceptions.
Folks - what Henning states is correct, Mon. or Tues. are more typical
closing days for museums and many restaurants. I would like to point out
again though that the Fri. 15th Aug. when the IETF wraps up is a public
holiday so don't expect to do your shopping in the afternoon and hop on
the return flight Sat. morning. Same goes for Austria BTW. Sat. 15th will
have norrmal (for here !) opening hours.
Most restaurants will still be open on the 15th but all shops will be closed.
>> Is this still true? Should I be thinking of driving (or taking a train)
>> to the Alps? Or will there be plenty to do in Munich itself on the Sunday
>> before IETF?
Either or - car or train to the Alps and Munich certainly has a lot to offer
on the Sun. as well. We're putting a pack together so folks can find their
way around.
Dave
>>
>> Craig
>
>--
>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 aa13760; 17 Apr 97 12:10 EDT
Received: from ecrc.de by ietf.org id aa13676; 17 Apr 97 12:09 EDT
Received: from scorpio.ecrc.de (scorpio.ecrc.de [141.1.4.100]) by ecrc.ecrc.de (8.8.3/8.8.3/$Revision: 1.2 $) with ESMTP id SAA26530; Thu, 17 Apr 1997 18:05:21 +0200 (MET DST)
Received: from acrab25.ecrc.de (acrab25.ecrc.de [141.1.6.125])
by scorpio.ecrc.de (8.8.3/8.8.4/$Revision: 1.4 $) with ESMTP
id SAA07171; Thu, 17 Apr 1997 18:05:20 +0200 (MET DST)
Sender:ietf-request at ietf.org
From: Dave Morton <Dave.Morton at ecrc.de>
Received: (from dave at localhost) by acrab25.ecrc.de (8.8.2/8.8.2/$Revision: 1.1 $) id SAA15052; Thu, 17 Apr 1997 18:05:19 +0200 (MET DST)
Date: Thu, 17 Apr 1997 18:05:19 +0200 (MET DST)
Message-Id: <199704171605.SAA15052 at acrab25.ecrc.de>
To: flanigab at ncr.disa.mil, ietf at ietf.org
Subject: Re: Call Sheraton Munich Direct (Was: Re[4]: Hotel space Munich)
Source-Info: From (or Sender) name not authenticated.
Yep - it seems the Sheraton Munich is not integrated in the Sheraton
US 800 number system for bookings so as Bill says please call or fax
the hotel directly. Here are again the coordinates:
Tel: +49 89 9264-0
Fax: +49 89 916 877
Sorry about the non-technical stuff on the list.
Dave
Received: from cnri by ietf.org id aa16944; 17 Apr 97 12:51 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15185;
17 Apr 97 12:51 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <NAA12690 at pad-thai.cam.ov.com>; Thu, 17 Apr 1997 13:56:27 GMT
Message-Id: <199704171356.JAA00549 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: Draft revision to CAT-WG charter
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 17 Apr 1997 09:56:11 -0400
From: John Linn <linn at cam.ov.com>
Precedence: bulk
CAT fanciers:
Fred Baker, the IETF chair, recently asked all WG chairs to update their
WGs' charters, a process which is reviewed with the appropriate Area
Director and, in some cases, by the IESG. Here's the working draft
I've compiled. Please send any comments, suggestions, corrections, or
discussion to the list NLT Friday, 25 April, in order that they can be
considered and reflected as appropriate in a version of the charter to
be sent to the Area Director thereafter.
Thanks, regards, ...
--jl
-----DRAFT REVISED CAT-WG CHARTER FOLLOWS-----
----------------------------------------------------------------------------
Common Authentication Technology (cat) Charter
Chair(s)
* John Linn <john.linn at ov.com>
Security Area Director(s):
* Jeffrey Schiller <jis at mit.edu>
Mailing List Information
* General Discussion:cat-ietf at mit.edu
* To Subscribe: cat-ietf-request at mit.edu
* Archive: ftp://bitsy.mit.edu/cat-ietf/archive/
Description of Working Group
The goal of the Common Authentication Technology (CAT) Working Group is to
provide distributed security services (including authentication, integrity,
confidentiality, and (in some cases) support for non-repudiation) to a
variety of protocol callers in a manner which insulates those callers from
the specifics of underlying security mechanisms.
By separating security implementation tasks from the tasks of integrating
security data elements into caller protocols, those tasks can be partitioned
and performed separately by implementors with different areas of expertise.
This provides leverage for the IETF community's security-oriented resources,
and allows protocol implementors to focus on the functions their protocols
are designed to provide rather than on characteristics of security
mechanisms. CAT seeks to encourage uniformity and modularity in security
approaches, supporting the use of common techniques and accommodating
evolution of underlying technologies.
In support of these goals, the working group pursues several interrelated
tasks. We have defined a common service interface allowing callers to invoke
security services in association-oriented environments, with an associated
token format identifying the security mechanism being employed. Revisions to
this document set are currently being finalized in response to
implementation experience. The CAT Working Group also defines underlying
mechanisms to provide security services, and supports integration of
security services into caller protocols. Related work areas include
interface and mechanism extensions under consideration for message
protection in store-and-forward environments, for mechanism selection via
negotiation, and for authorization support.
Goals and Milestones
Jun 97
Submit Negotiated Mechanism document to IESG for consideration as a
Proposed Standard.
Jun 97
Issue Internet-Draft representing updated version of RFC-2078, aligned
with GSS-V2 C bindings Internet-Draft.
Jun 97
Submit GSS-V2 C bindings document to IESG for consideration as a
Proposed Standard.
Jun 97
Submit revised version of RFC-1510 (Kerberos) to IESG for consideration
as a Draft Standard.
Aug 97
Review status of WG Internet-Drafts and plan follow-on activities.
Current Internet-Drafts
* FTP Security Extensions (56442 bytes)
* Independent Data Unit Protection Generic Security Service Application
Program Interface (IDUP-GSS-API) (143091 bytes)
* Public Key Cryptography for Initial Authentication in Kerberos (26001
bytes)
* Generic Security Service API Version 2 : C-bindings (213656 bytes)
* Simple GSS-API Negotiation Mechanism (25818 bytes)
* The SESAME V5 GSS-API Mechanism (133513 bytes)
* Extended Generic Security Service APIs: XGSS-APIs Access control and
delegation extensions (52472 bytes)
* Public Key Cryptography for Cross-Realm Authentication in Kerberos
(12602 bytes)
* Key Derivation for Kerberos V5 (8426 bytes)
* Triple DES with HMAC-SHA1 Kerberos Encryption Type (3830 bytes)
* Public Key Utilizing Tickets for Application Servers (PKTAPP) (11099
bytes)
* Kerberos Change Password Protocol (10163 bytes)
* Integrity Protection for the Kerberos Error Message (10021 bytes)
Request for Comments
* Generic Security Service Application Program Interface (RFC 1508)
(111228 bytes)
* The Kerberos Network Authentication Service (V5) (RFC 1510) (275395
bytes)
* DASS - Distributed Authentication Security Service (RFC 1507) (287809
bytes)
* Generic Security Service API : C-bindings (RFC 1509) (99605 bytes)
* Common Authentication Technology Overview (RFC 1511) (4185 bytes)
* The Kerberos Version 5 GSS-API Mechanism (RFC 1964) (47413 bytes)
* The Simple Public-Key GSS-API Mechanism (SPKM) (RFC 2025) (101692
bytes)
* Generic Security Service Application Program Interface, Version 2
(GSS-V2) (RFC 2078) (185990 bytes)
----------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa20172; 17 Apr 97 13:46 EDT
Received: from limes.NIC.DTAG.DE by ietf.org id aa20025; 17 Apr 97 13:44 EDT
Received: from kronos.NIC.DTAG.DE (kronos.NIC.DTAG.DE [194.25.1.92]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id TAA15516; Thu, 17 Apr 1997 19:38:59 +0200 (MET DST)
Received: from kronos.NIC.DTAG.DE (localhost [127.0.0.1]) by kronos.NIC.DTAG.DE (8.8.5/8.7.1) with ESMTP id TAA24167; Thu, 17 Apr 1997 19:41:00 +0200 (MET DST)
To: ietf at ietf.org
cc: Dave Morton <Dave.Morton at ecrc.de>
Subject: Re: Munich on Sunday
In-reply-to: Your message of "Thu, 17 Apr 1997 17:55:03 +0200."
<199704171555.RAA15038 at acrab25.ecrc.de>
Date: Thu, 17 Apr 1997 19:40:59 +0200
Message-ID: <24161.861298859 at kronos.NIC.DTAG.DE>
Sender:ietf-request at ietf.org
From: Ruediger Volk <rv at kronos.nic.dtag.de>
Source-Info: From (or Sender) name not authenticated.
a comment on Dave Morton's warning
> ... I would like to point out
> again though that the Fri. 15th Aug. when the IETF wraps up is a public
> holiday so don't expect to do your shopping in the afternoon and hop on
> the return flight Sat. morning. Same goes for Austria BTW. Sat. 15th will
> have norrmal (for here !) opening hours.
actually the hollyday does *not* apply all over Germany - my calendar lists
"Mariae Himmelfahrt" only for "parts for Saarland and part of Bavaria";
I have no idea what parts of Bavaria are supposed to work on August 15th.
Ruediger
Received: from ietf.org by ietf.org id aa17942; 18 Apr 97 7:03 EDT
Received: from ecrc.de by ietf.org id aa17591; 18 Apr 97 6:51 EDT
Received: from scorpio.ecrc.de (scorpio.ecrc.de [141.1.4.100]) by ecrc.ecrc.de (8.8.3/8.8.3/$Revision: 1.2 $) with ESMTP id MAA10429; Fri, 18 Apr 1997 12:48:11 +0200 (MET DST)
Received: from acrab25.ecrc.de (acrab25.ecrc.de [141.1.6.125])
by scorpio.ecrc.de (8.8.3/8.8.4/$Revision: 1.4 $) with ESMTP
id MAA11029; Fri, 18 Apr 1997 12:48:10 +0200 (MET DST)
Sender:ietf-request at ietf.org
From: Dave Morton <Dave.Morton at ecrc.de>
Received: (from dave at localhost) by acrab25.ecrc.de (8.8.2/8.8.2/$Revision: 1.1 $) id MAA16294; Fri, 18 Apr 1997 12:48:09 +0200 (MET DST)
Date: Fri, 18 Apr 1997 12:48:09 +0200 (MET DST)
Message-Id: <199704181048.MAA16294 at acrab25.ecrc.de>
To: ietf at ietf.org, rv at kronos.nic.dtag.de
Subject: Re: Munich on Sunday
Cc: Dave.Morton at ecrc.de
Source-Info: From (or Sender) name not authenticated.
>a comment on Dave Morton's warning
> > ... I would like to point out
> > again though that the Fri. 15th Aug. when the IETF wraps up is a public
> > holiday so don't expect to do your shopping in the afternoon and hop on
> > the return flight Sat. morning. Same goes for Austria BTW. Sat. 15th will
> > have norrmal (for here !) opening hours.
>actually the hollyday does *not* apply all over Germany - my calendar lists
>"Mariae Himmelfahrt" only for "parts for Saarland and part of Bavaria";
>I have no idea what parts of Bavaria are supposed to work on August 15th.
No parts. Its a public holiday in both Bavaria and in all of Austria - who
cares about the rest of Germany, the attendees are in Munich and will most
likely be heading towards Austria or hanging around Bavaria somewhere. If anyone
fancies an afternoon in Berlin the shops are open there of course.
Dave
> Ruediger
Received: from ietf.org by ietf.org id aa20418; 18 Apr 97 9:19 EDT
Received: from rip.psg.com by ietf.org id aa20289; 18 Apr 97 9:13 EDT
Received: by rip.psg.com
id m0wIDQf-0007zdC; Fri, 18 Apr 97 06:10 PDT (Smail3.1.29.1#1)
Message-Id: <m0wIDQf-0007zdC at rip.psg.com>
Date: Fri, 18 Apr 97 06:10 PDT
Sender:ietf-request at ietf.org
From: Randy Bush <randy at psg.com>
To: Dave Morton <Dave.Morton at ecrc.de>
Cc: ietf at ietf.org
Subject: Re: Munich on Sunday
References: <199704181048.MAA16294 at acrab25.ecrc.de>
Source-Info: From (or Sender) name not authenticated.
> who cares about the rest of Germany,
Since you asked, I do. Probably a few others too. I guess I need not purge
my filter for Bayern thinking it is all of Germany. :-)/2
randy
Received: from ietf.org by ietf.org id aa22271; 18 Apr 97 9:54 EDT
Received: from ietf.ietf.org by ietf.org id aa21917; 18 Apr 97 9:52 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-msg-fmt-01.txt
Date: Fri, 18 Apr 1997 09:52:50 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704180952.aa21917 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 : Message Format Standard
Author(s) : P. Resnick
Filename : draft-ietf-drums-msg-fmt-01.txt
Pages : 18
Date : 04/17/1997
This standard specifies a syntax for text messages that are sent between
computer users, within the framework of "electronic mail" messages. This
standard supersedes the one specified in Request For Comments 822,
"Standard for the Format of ARPA Internet Text 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-drums-msg-fmt-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-drums-msg-fmt-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-drums-msg-fmt-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: <19970417105244.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-drums-msg-fmt-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-drums-msg-fmt-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970417105244.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22278; 18 Apr 97 9:54 EDT
Received: from ietf.ietf.org by ietf.org id aa22002; 18 Apr 97 9:53 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-white-protocol-stack-00.txt
Date: Fri, 18 Apr 1997 09:53:10 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704180953.aa22002 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : NETBLT (Network Block Transfer Protocol)
Author(s) : J. White
Filename : draft-white-protocol-stack-00.txt
Pages : 25
Date : 04/16/1997
The NETBLT protocol [RFC998] was designed as an experimental transport
layer protocol, intended for moving large quantities of data across a wide
variety of networks. It provides reliable bulk transfer with an end-to-end
flow-control mechanism meant to deal with network congestion by throttling
the rate at which data is inserted into the network. However, experiments
with NETBLT across shared links revealed problems with fairness; traffic
from one connection could hog most of a link's bandwidth, and there seems
to be no way to prevent this under the current rate-control scheme, so
further application of NETBLT was not pursued by its original developers.
However, NETBLT has a number of characteristics which make it very
attractive for use across noisy, long-delay, slow-turnaround, or asymmetric
communications links. Such links are common in military usage, and may
become more widespread with the development of mobile computing. NETBLT's
attractive characteristics include selective retransmission of lost
packets, potentially large transmission windows, and control of
transmission from the receiving, rather than the sending side; the latter
makes NETBLT relatively insensitive to network delays. NETBLT, with minor
modifications, was adopted as the transport layer of the military standard
TACO2 (Tactical Communications Protocol 2) [MIL- STD], which is intended
for the transmission of images and other bulk data across links that
cannot support the usual TCP/IP operation. This document describes NETBLT
as it is currently used, and is intended partly to encourage consideration
of NETBLT in other difficult communications environments.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-white-protocol-stack-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-white-protocol-stack-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-white-protocol-stack-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: <19970417144331.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-white-protocol-stack-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-white-protocol-stack-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970417144331.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22277; 18 Apr 97 9:54 EDT
Received: from ietf.ietf.org by ietf.org id aa21960; 18 Apr 97 9:53 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-weider-cip-hierarchy-00.txt
Date: Fri, 18 Apr 1997 09:52:59 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704180953.aa21960 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Hierarchical Extensions to the Common Indexing Protocol
Author(s) : C. Weider, P. Leach
Filename : draft-weider-cip-hierarchy-00.txt
Pages : 15
Date : 04/17/1997
This work explores what, in the parlance of the current CIP draft, is
called an index type -- specifically, a new kind of index that merges
indexing of hierarchically named attribute-value entities (such as in LDAP
and RWHOIS) and ones without distinguished names (such as in WHOIS++). It
is based on a previous version of the CIP specification, but that was just
a convenient syntactical jumping off point. It is intended to be orthogonal
to the FIND working group task of defining a framing syntax and
functionality for a common indexing data wrapping protocol, and that the
concepts and protocol elements in this draft should be able to be expressed
in a manner consistent with the new CIP framework at the appropriate time.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-weider-cip-hierarchy-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-weider-cip-hierarchy-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-weider-cip-hierarchy-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: <19970417104555.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-weider-cip-hierarchy-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-weider-cip-hierarchy-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970417104555.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22624; 18 Apr 97 9:55 EDT
Received: from ietf.ietf.org by ietf.org id aa22135; 18 Apr 97 9:53 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: ietf-sasl at imc.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-myers-auth-sasl-09.txt
Date: Fri, 18 Apr 1997 09:53:55 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704180953.aa22135 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-09.txt
Pages : 14
Date : 04/17/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-09.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-myers-auth-sasl-09.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-myers-auth-sasl-09.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970417110115.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-myers-auth-sasl-09.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-myers-auth-sasl-09.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970417110115.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22681; 18 Apr 97 9:55 EDT
Received: from ietf.ietf.org by ietf.org id aa22217; 18 Apr 97 9:54 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-vangulik-http-search-00.txt
Date: Fri, 18 Apr 1997 09:54:09 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704180954.aa22217 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : HTTP based Spatial and Temporal Searching.
Author(s) : C. Best, D. van Gulik
Filename : draft-vangulik-http-search-00.txt
Pages : 15
Date : 04/17/1997
This draft specifies the first three levels of operation of an http based
distributed search protocol. It is designed for parallel client-side
searching of geospatial catalogues. An important design objective is to
minimize the impact and extra resources for catalogue sites which already
have existing WWW gateways and search interfaces.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-vangulik-http-search-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-vangulik-http-search-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-vangulik-http-search-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: <19970417154915.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-vangulik-http-search-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-vangulik-http-search-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970417154915.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22758; 18 Apr 97 9:55 EDT
Received: from ietf.ietf.org by ietf.org id aa22272; 18 Apr 97 9:54 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-control-flow-00.txt
Date: Fri, 18 Apr 1997 09:54:16 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704180954.aa22272 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integrated Services Working
Group of the IETF.
Title : A Measurement Based Admission Control Algorithm for
Controlled-Load Service
Author(s) : S. Jamin, L. Breslau
Filename : draft-ietf-intserv-control-flow-00.txt
Pages : 7
Date : 04/17/1997
Controlled-Load Service provides data flows with an enhanced quality of
service, in the form of low packet delay and a low probability of packet
loss even under congestion. A network element providing Controlled-Load
Service must use an admission control algorithm to limit the number of data
flows receiving the service. In this document we describe an admission
control algorithm for Controlled-Load Service. This algorithm is not
intended for IETF standardization. Rather, it is presented for
informational purposes only.
Internet-Drafts are available by anonymous FTP. 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-control-flow-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-intserv-control-flow-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-intserv-control-flow-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: <19970417162913.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-intserv-control-flow-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-intserv-control-flow-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970417162913.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22757; 18 Apr 97 9:55 EDT
Received: from ietf.ietf.org by ietf.org id aa22321; 18 Apr 97 9:54 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-thayer-sec-exp-00.txt
Date: Fri, 18 Apr 1997 09:54:21 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704180954.aa22321 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IPSEC File Import/Export Format
Author(s) : R. Thayer, N. Doraswamy
Filename : draft-thayer-sec-exp-00.txt
Pages : 23
Date : 04/17/1997
Under certain conditions it is necessary to configure hosts running IP
Security [RFC-1825] with security parameters and other information in an
out-of-band manner. This draft defines a file format that may be used to
exchange such information via removable media or distribution via a web
server.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-thayer-sec-exp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-thayer-sec-exp-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-thayer-sec-exp-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: <19970417170650.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-thayer-sec-exp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-thayer-sec-exp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970417170650.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22790; 18 Apr 97 9:55 EDT
Received: from ietf.ietf.org by ietf.org id aa22474; 18 Apr 97 9:54 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-dobbins-00.txt
Date: Fri, 18 Apr 1997 09:54:37 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704180954.aa22474 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Address Resolution and Location Discovery (ARLD)
Protocol
Author(s) : K. Dobbins, T. Grant, D. Ruffen, E. Ziegler
Filename : draft-rfced-info-dobbins-00.txt
Pages : 15
Date : 04/16/1997
The Address Resolution and Location Discovery (ARLD) protocol is part of
the InterSwitch Message Protocol (ISMP). ISMP was designed to facilitate
interswitch communication within distributed connection-oriented switching
networks. The ARLD protocol is used to resolve a packet destination
address when the source and destination pair of a packet does not match a
known connection. It is also used to provide end-station address mobility
between switches.
Internet-Drafts are available by anonymous FTP. 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-dobbins-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-dobbins-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-dobbins-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: <19970416161555.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-dobbins-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-dobbins-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970416161555.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22806; 18 Apr 97 9:55 EDT
Received: from ietf.ietf.org by ietf.org id aa22468; 18 Apr 97 9:54 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-grant-00.txt
Date: Fri, 18 Apr 1997 09:54:34 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704180954.aa22468 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Switched Fabric Connection Tap (SFCT) Protocol
Author(s) : K. Dobbins, T. Grant, J. Liessner, D. Ruffen
Filename : draft-rfced-info-grant-00.txt
Pages : 12
Date : 04/16/1997
The Switched Fabric Connection Tap (SFCT) protocol is part of the
InterSwitch Message Protocol (ISMP). ISMP was designed to facilitate
interswitch communication within distributed connection-oriented switching
networks. The SFCT protocol is used to monitor communication between two
end stations.
Internet-Drafts are available by anonymous FTP. 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-grant-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-grant-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-grant-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: <19970416160758.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-grant-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-grant-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970416160758.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa09222; 18 Apr 97 15:48 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17677;
18 Apr 97 15:48 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <SAA11638 at pad-thai.cam.ov.com>; Fri, 18 Apr 1997 18:12:18 GMT
From: Tony Mione <mione at boeing.rutgers.edu>
Message-Id: <9704181412.ZM10057 at boeing.rutgers.edu>
Date: Fri, 18 Apr 1997 14:12:12 -0400
X-Mailer: Z-Mail (3.2.1 15feb95)
To: cat-ietf at mit.edu
Subject: Recommended enhancement to PK-CROSS
Cc: mione at hardees.rutgers.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
After some off-line discussions with Brian Tung, I have a
recommendation for handling expiration of symmetric keys
generated for cross-realm authentication. Please pardon any ASN.1 errors or
hand-waving as I am partially ASN.1-challenged.
Essentially, the differences simply involve sending a lifetime
(in seconds) along with the random symmetric key. When cross-realm
authentication is requested of the local kdc, it checks its out bound cache
for a profile. If the profile is present for the remote realm, it checks
the expiration time in the profile. If the key is expired, it follows the
standard pk authentication as described in your document to acquire a new
symmetric key. Otherwise, it uses the symmetric key from the existing profile.
The changes to the structures in the existing PK-CROSS document are
as follows:
1) add a lifetime (in seconds) to the RemoteReply structure and
the PKCrossOutput structure.
PKCrossOutput ::= SEQUENCE {
certificate [0] OCTET STRING OPTIONAL,
-- public key certificate
-- of local KDC
encSharedKey [1] EncryptedData,
-- of type EncryptionKey
-- containing random symmetric key
-- encrypted using public key
-- of remote KDC
sharedKeyLifetime [2] INTEGER,
-- Local KDC's preferred
-- lifetime of EncryptionKey
-- in seconds
sigSharedKey [3] Signature,
-- of encSharedKey
-- using signature key
-- of local KDC
pkEncData [4] EncryptedData,
-- (normally) of type EncTktPart
-- encrypted using encryption key
-- found in encSharedKey
}
RemoteReply ::= [APPLICATION 42] SEQUENCE {
trustedCertifiers [0] SEQUENCE OF PrincipalName,
certificates[1] SEQUENCE OF Certificate,
encTypeToUse [2] SEQUENCE OF INTEGER,
-- encryption types usable
-- for encrypting pkEncData
sharedKeyLifetime [3] INTEGER
-- Remote KDC's preferred key
-- lifetime (in seconds)
}
Additionally, to be sure that the remote KDC has received the
PKCrossOutput message (in case the local KDC desires a shorter expiration
time than the remote KDC), have the remote KDC send a PKCrossOutputAck
message containing the minimum of the two lifetimes.
PKCrossOutputAck ::= SEQUENCE {
agreedSharedKeyLifetime [0] INTEGER
-- Minimum of the kdc
-- shared key lifetimes
}
This makes the entire interchange look like the following:
[local Client] [local KDC] [Remote KDC]
AS_REQ [RRealm] ----->
RemoteRequest --------->
(nonce)
<--------------- RemoteReply
(certs,CAs,lifetime1)
PkCrossOutput --------->
(certs,key,lifetime2)
<--------------- PkCrossOutputAck
(min(lifetime1,lifetime2))
That's about it. I am interested in hearing comments or feedback
on this suggestion.
--
Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 908-445-0650
mione at nbcs-ns.rutgers.edu W3: http://www-ns.rutgers.edu/~mione/
PGP Fingerprint : E2 25 2C CD 28 73 3C 5B 0B 91 8A 4E 22 BA FA 9F
Editorial Advisor for Digital Systems Report ***** Important: John 17:3 *****
Received: from ietf.org by ietf.org id aa09950; 18 Apr 97 16:13 EDT
Received: from zephyr.isi.edu by ietf.org id aa09595; 18 Apr 97 16:02 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA01018>; Fri, 18 Apr 1997 12:59:08 -0700
Message-Id: <199704181959.AA01018 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2138 on RADIUS
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 18 Apr 97 12:59:08 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2138:
Title: Remote Authentication Dial In User Service
(RADIUS)
Author: C. Rigney, A. Rubens, W. Simpson, S. Willens
Date: April 1997
Mailbox: cdr at livingston.com, acr at merit.edu,
wsimpson at greendragon.com, steve at livingston.com
Pages: 65
Characters: 120407
Updates/Obsoletes: 2058
URL: ftp://ds.internic.net/rfc/rfc2138.txt
This document describes a protocol for carrying authentication,
authorization, and configuration information between a Network Access
Server which desires to authenticate its links and a shared
Authentication Server. This document is a product of the Remote
Authentication Dial-In User Service Working Group of the IETF.
Implementation Note: This memo documents the RADIUS protocol. There
has been some confusion in the assignment of port numbers for this
protocol. The early deployment of RADIUS was done using the
erroneously chosen port number 1645, which conflicts with the
"datametrics" service. The officially assigned port number for RADIUS
is 1812.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970418125028.RFC at ISI.EDU>
SEND /rfc/rfc2138.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2138.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970418125028.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09949; 18 Apr 97 16:13 EDT
Received: from zephyr.isi.edu by ietf.org id aa09768; 18 Apr 97 16:07 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA01276>; Fri, 18 Apr 1997 13:04:04 -0700
Message-Id: <199704182004.AA01276 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2139 on RADIUS Accounting
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 18 Apr 97 13:04: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 2139:
Title: RADIUS Accounting
Author: C. Rigney
Date: April 1997
Mailbox: cdr at livingston.com
Pages: 25
Characters: 44919
Updates/Obsoletes: 2059
URL: ftp://ds.internic.net/rfc/rfc2139.txt
This document describes a protocol for carrying accounting
information between a Network Access Server and a shared Accounting
Server. This document is the product of the Remote Authentication
Dial-In User Service Working Group of the IETF.
Implementation Note: This memo documents the RADIUS Accounting
protocol. There has been some confusion in the assignment of port
numbers for this protocol. The early deployment of RADIUS Accounting
was done using the erroneously chosen port number 1646, which
conflicts with the "sa-msg-port" service. The officially assigned
port number for RADIUS Accounting is 1813.
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: <970418130036.RFC at ISI.EDU>
SEND /rfc/rfc2139.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2139.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970418130036.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa15834; 18 Apr 97 19:35 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17499;
18 Apr 97 19:35 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <WAA21186 at pad-thai.cam.ov.com>; Fri, 18 Apr 1997 22:05:52 GMT
Date: Fri, 18 Apr 97 17:24:19 EST
From: William Curtin <curtinw at ftm.disa.mil>
Message-Id: <9703188614.AA861411912 at ftm.disa.mil>
To: cat-ietf at mit.edu, ftp-wg at hops.ag.utk.edu
Subject: Re: Ftp-WG: Comments on FTP Security Extensions draft
Precedence: bulk
I know that this document is out for last call so I hope my
comments are not too late. I'm packing to leave for a week
long meeting but wanted to get this out before I left.
1. The new command defined for FTP in this document will
need to be supported by the FEAT command (currently defined
in draft-ietf-ftpext-mlst-00.txt). I guess given that this
draft will progress to RFC status before the MLST draft that
the definitions for these commands to a FEAT response will
have to be done in the MLST or another document.
Are there standard formats to define the security mechanisms
associated with a AUTH command?
2. Does the priori knowledge of a small set of commands
(containing few characters) lend to breaking the algorithm
associated with a security mechanism and thus possibly give
a false sense of security? For example I can assume that FTP
will be sending CWD over the control connection during the
session.
I recognize that anything is better than sending commands in
the clear.
3. Will these commands be mandatory for all clients and
servers?
4. I don't think the draft is clear on the use of CCC, MIC,
CONF, and ENC commands. That is do I default to CCC even
though I may have negotiated a level of confidentiality or
are they automatically set?
5. Reference to Section 9 on page 6 should be Section 10.
6. The paragraph in the CCC command section starting "If
unprotected commands are ..." seems out of place. This seems
more of an introductory paragraph. I would suggest that the
commands be broken into 3 sections:
3.1 Security Identification and Negotiation
3.2 Data Port Security
3.3 Command Port Security.
7. Are these two paragraphs from page 8 the same?
"If the server has not completed a protection buffer size
negotiation with the client, it should respond with a 503
reply code."
"The PROT command will be rejected and the server should
reply 503 if no previous PBSZ command was issued."
bill
Received: from ietf.org by ietf.org id aa17753; 18 Apr 97 21:00 EDT
Received: from cbgw1.lucent.com by ietf.org id aa17485; 18 Apr 97 20:51 EDT
Received: from holta.ho.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2)
id UAA10862; Fri, 18 Apr 1997 20:40:32 -0400
Received: by holta.ho.lucent.com (5.x/EMS-L sol2)
id AA02134; Fri, 18 Apr 1997 20:48:14 -0400
Sender:ietf-request at ietf.org
From: Igor Faynberg <faynberg at lucent.com>
Received: by holta.ho.lucent.com (5.x/EMS-L sol2)
id AA02126; Fri, 18 Apr 1997 20:48:13 -0400
Date: Fri, 18 Apr 1997 20:48:13 -0400
Message-Id: <9704190048.AA02126 at holta.ho.lucent.com>
Original-From: igorf at holta.ho.lucent.com (Igor Faynberg)
To: ietf at ietf.org
Subject: Announcement
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Dear Ietf at ietf-org:
Could you please send the attached announcement on my behalf?
(The mailing list has been sanctioned by the Application Area Directors,
Harald Alvestrand and Keith Moore.
If you have any questions, please send me the E-mail or
call me on +1-908-949-0137.
Thanks,
Igor Faynberg
***************** ANNOUNCEMENT *********************
The mailing list for the discussion started at the PSTN/Internet
Interworking (pint) BOF has been established; the list is maintained at
Bell Laboratories/Lucent Technologies. For all issues that may need a human
contact, please get in touch with Igor Faynberg (faynberg at bell-labs.com,
+1-908-949-0137).
The mailing list's address (which should be used for sending messages
to the group) is 'pint at lists.research.bell-labs.com'.
To subscribe, please send E-mail to
'pint-request at lists.research.bell-labs.com'
with the word "subscribe" on the first line fo the message. To remove yourself
from the mailing list please send to the above address a message with the
word "unsubscribe" on the first line .
The archive capability is available: You can send email to
'majordomo at lists.research.bell-labs.com'
with a command of the form 'get pint archive.<YYMMDD>', which will
result in sening to you all messages received on the day <DD> of the month <MM>
of the year <YY>. (Thus, sending 'get pint archive.970515'
would request all the messages sent on May 15, 1997.) The command
'get pint CONTENTS' requests the table of contents of all the messages you
can get.
Received: from ietf.org by ietf.org id aa09375; 19 Apr 97 10:02 EDT
Received: from SYNW06.elettra.trieste.it by ietf.org id aa08938;
19 Apr 97 9:48 EDT
Date: Sat, 19 Apr 1997 15:45:21 +0200
To: ietf at ietf.org
Message-Id: <970419154521.60600982 at elettra.trieste.it>
Sender:ietf-request at ietf.org
From: "Claudio Allocchio, +39 40 3758523" <Claudio.Allocchio at elettra.trieste.it>
Subject: Munich IETF...
Source-Info: From (or Sender) name not authenticated.
:-)
just a short "comment" at least by myself and the group which runs their
cars with an "I" on the back... (or from a domain ending with ".it")...
organizing an IETF the week of August 15th is really a BAD idea... all of
us (as about 80 % of Italians) are on holiday the week of August 15th,
thus we will have to skip holidays to come to the IETF...
:-)
no... no... don't start saying in Italy there are always Holidays...
Finland, then UK, then Ireland, then Germany and finally Italy
(source USA Today, on week ago...) :-)
smiley regards,
Claudio
Received: from ietf.org by ietf.org id aa12996; 19 Apr 97 13:12 EDT
Received: from caladan.arrakis.es by ietf.org id aa12704; 19 Apr 97 12:58 EDT
Received: from pc-de-raides-j. (ie-192.arrakis.es [195.5.74.192]) by arrakis.es (8.7.5/8.7.3) with SMTP id SAA17403 for <ietf at ietf.org>; Sat, 19 Apr 1997 18:54:44 +0200 (MET DST)
Message-Id: <199704191654.SAA17403 at arrakis.es>
Comments: Authenticated sender is <raidesj at pop3.arrakis.es>
Sender:ietf-request at ietf.org
From: Dr-X <raidesj at arrakis.es>
Organization: Dr-X Enterprises, Ltd.
To: ietf at ietf.org
Date: Sat, 19 Apr 1997 17:56:42 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: Quoted-printable
Subject: What has happened?
Priority: normal
X-mailer: Pegasus Mail for Win32 (v2.53/R1)
Source-Info: From (or Sender) name not authenticated.
Dear Sirs/Ladies all across the IETF:
=BFWhat has happened in the days off I've just taken? ... I ask this
because it seems that my complains have been heard and some one took
care of sending me almost any possible Get locator for every IETF
Draft currently on the pipelines! .. I don't know if that was cause
of my complains or only a coincidence, but it's very welcome. I'm
going to study carefully each Draft to decide when and where in the
discussion to adhere/disagree if needed ... I've been always waiting
for a chance to touch the real world technology difficulties and
solutions paths and hope my minute colaboration will be useful if
any! ... Thanks to all that answered my complains and sorry to all
the bothered people around...
By the way ... =BFhow about an "packet size on behalf of the
connection speed" mechanism to serve multiple simultaneous petitions
for data download from a server just not to clog it and, at the same
time, serve people at their highest speeds? ... I mean that, if you
have a server tied to a T1 line and there comes an HTTP request for a
WEB page from a 22.8 kbps modem and then a request for the same page
from a BRI 128Kbps RDSI line, =BFwhy not to send the page as a whole
(graphics, sound, etc included - providing of course they're all in
the requested server) to them, but in bigger packets to the RDSI line
than to the 28.8 modem? ... I know that it will depend too on the
path-to-client bottlenecks, but with a previous protocol-controlled
route determination info exchanged between the server and each client
it'll be possible (or not?) ... Of course, this is only an errant
idea, not even a Draft Proposal but a sort of customary RFC ... (I
will look around to see if this is yet on the pipeline or already
done later, but as an example of what can I propose/think of I
believe it's fairly ok!) ... Or what about the use of META-HTML in
WEB authoring to help with the creation of standard templates? (i'm
currently using some form of this to facilitate my publication of
mIRC Help File translation to Spanish in my web-site - using a
hand-coded filter from META-HTML to HTML, of course!)
-----
XXX XXX
DDDD RRRR XX XX
D D R R XX XX
D D R R XX XX
D D RRRR ----- XXXX ... ON THE EDGE OF TECHNOLOGY
D D R R XX XX
D D R R XX XX
DDDD R R XX XX
XXX XXX
Received: from ietf.org by ietf.org id aa08605; 20 Apr 97 12:29 EDT
Received: from cnri by ietf.org id aa08194; 20 Apr 97 12:14 EDT
Received: from tsmi.iitri.com by CNRI.Reston.VA.US id aa25438;
20 Apr 97 12:14 EDT
Received: from mailcenter.tsmi.iitri.com (mailserver.tsmi.iitri.com) by boutwell.tsmi.iitri.com (4.1/3.1.090690-IITRI-TSMI)
id AA02016; Sun, 20 Apr 97 12:13:39 EDT
Message-Id: <n1350584179.48758 at mailcenter.tsmi.iitri.com>
Date: 20 Apr 1997 12:10:29 -0400
Sender:ietf-request at ietf.org
From: "Omidyar, Guy" <gomidyar at mailcenter.tsmi.iitri.com>
Subject: Final Program -MWCN'97-Paris France, May 12-15
To: IEEETCPC at listserv.utoronto.ca, ietf at CNRI.Reston.VA.US, itc at fokus.gmd.de,
TCCC at ieee.org
X-Mailer: Mail*Link SMTP-MS 3.0.2
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; Name="Message Body"
Content-Transfer-Encoding: quoted-printable
Source-Info: From (or Sender) name not authenticated.
*************-Final Program and Registration Form-************
*****************************MWCN'97****************************
First International Workshop On Mobile and Wireless Communications
Networks.
For workshop information and program also visit the Web location:
http://www.prism.uvsq.fr
or
http://www.prism.uvsq.fr/~marefat/mwcn/mwcn97.html
Workshop Location:
Room Louis Liard, Sorbonne, Place de la Sorbonne, Quartier Latin, Paris,
France
May 12-15, 1997
Tutorials 12-13 and Workshop 14-15
Sponsored by the University of Versailles-PRiSM Laboratory
and in cooperation with the
ACM SIGMOBILE
IFIP TC6, WG6.8
IEEE ComSoc Technical Committee on
Communications System Integration and Modeling
General Co-Chairs:
Guy Pujolle, University of Versailles
Guy Omidyar, Illinois Institute of Technology RI
Technical Program Committee:
A. Charbonnier, France Telecom, France
J.P. Claude, PRiSM, University of Versailles, France
J. Daigle, University of Mississippi, USA
Ph.Godlevski, ENST, France
V.B. Iversen, TUD, Denmark
B. Jabbari, George Mason University, USA
O. Martikainen Telecom Finland, Finland
M. Naghshineh, IBM, T.J. Watson research, USA
G. Omidyar, Illinois Institute of Technology Research Institute, USA
K. Pahlavan, Worcester Polytechnic Institute, USA
H. Perros, NCSU, USA
R. Pickholtz, The George Washington University, USA
G. Pujolle, PRiSM, University of Versailles, France
I. Rubin, UCLA, USA
K.S. Shanmugan, University of Kansas, USA
M. Schwartz, Columbia University
J. Slavik, Testcom, Czech Rep.
O. Spaniol, Technical University Aachen, Germany
S. Tabbane, ESPTT, Tunisia
V. Veque, LRI, University of Paris XI, France
D. Zeghlache, INT, France
MWCN Standing Committee:
Guy Omidyar: Chair
Local arrangement: K. Al Agha (PRiSM)
-----------------------------------------------
Tutorials Before the Workshop
Registration will be open from 8:00 am
Both for Tutorials and the MWCN'97 Workshop
(Location and address for Tutorials will Be Announced)
Monday 12 May (Morning)
Tutorial - 1
Wired and Wireless ATM
G. Omidyar
(Illinois Institute of Technology Research Institute, USA)
9:30am to 10:30am
10:30am coffee break
11:00am to 11:30pm
Monday 12 May (Afternoon)
Tutorial - 2
UMTS (Universal Mobile Telecomunication System)
P. Lucas (GIE CEGETEL, France)
1:30pm to 3:30pm
3:30pm coffee break
4:00pm to 5:00pm
Tuesday 13 May (Morning)
Tutorial - 3
Wireless ATM
E. Ayanoglu (Bell Labs, Lucent/AT&T, USA)
8:30am to 10:30am
10:30am coffee break
11:00am to 12:00pm
Tuesday 13 May (Afternoon)
Tutorial - 4
Wireless LANs
A. Wolisz (Technical University of Berlin, Germany)
1:30pm to 3:30pm
3:30pm coffee break
4:00pm to 5:00pm
---------------------------------------
MWCN'97 Workshop Advance program
Wednesday 14 May, 1997
Registration will be open from 8:00 am
--------------------------------------
Wednesday 14 May
9:00 am
Opening Remarks: G. Omidyar and G. Pujolle
Track 1 : Access techniques
Chairman : O. Spaniol
(Technical University Aachen, Germany)
1- GSM in the future evolution towards UMTS
R Thomas (CNET, France Telecom)
2- An overview of Third Generation Mobile Networks : Architecture
Principles
P. Lucas (GIE CEGETEL, France)
10 :30 am
Break
11:00
Track 2 : The Next Steps
Chairman : J. Slavik (Testcom, Czech Rep.)
1- The next steps for Mobile Computing and Communication
G. Q. Maguire Jr. (KTH/Inst. for Teleinformatik, Sweden)
2- Ubiquitous and Personal
I. Chlamtac (The University of Texas at Dallas, USA)
3- Packet access techniques for wireless systems
F. Borgonovo, A. Capone, L. Fratta, L. Musumeci
(Politecnico di Milano, Italy)
12 :30 pm
Lunch
13:30 pm - 14:00 pm
Standing Committee Meeting (All Invited)
Planning for the Next Year Conference/Workshop (MWCN'98 Conference)
14 :00 pm
Track 3 : Mobile, Wireless and Internet
Chairman : D. Zeghlache, (INT, France)
1- Mobile IP : a Tutorial
C. E. Perkins (Sun, USA)
2- Wireless LANs in Internet
A. Wolisz (Technical University of Berlin, Germany)
3- Local Wideband Wireless Networks
K. Pahlavan, (Worcester Polytechnic Institute, USA)
15:30 pm
Break
16:00 pm
Track 4 : Channel control
Chairman : K. Pahlavan, Worcester Polytechnic Institute, USA
1- Optimal Channel utilization and Service Protection in Cellular
Communication Systems
V. B. Iversen (Technical University of Denmark, Denmark)
2- Metaservices Channel Assignment in Third Generation Wireless Network
F. Valois (PRiSM), University of Versailles, France)
V. Veque, LRI, University of Paris-Sud, France)
3- An Application of Intelligent Agents for Mobile Network Resource
Allocation.
K. Al Agha (INT and PRiSM, France)
19:30 pm Dinner (Location to be provided)
---------------------------
Second Day
Thursday 15 May
---------------------------
Registration will be open from 8:00 am
09:00 am
Track 5 : Towards a new generation
Chairman : S. Tabbane, (ESPTT, Tunisia)
1- An introduction of Location Management in Third Generation Cellular
Networks
N. Faggion (GIE CEGETEL, France)
2- Planification of the fixed network in a cellular network
M. Marzoug (CNET, France T=E9l=E9com, France)
3- Services Continuation from Fixed to Wireless ATM Network
J. Ben-Othman (PRiSM, University of Versailles, France)
V. Veque (LRI, University of Paris-Sud, France)
10:30 am
Break
11 :00 am
Track 6 : Wireless and ATM
Chairman : J.P. Claude (PRiSM, France)
1- Wireless ATM overview - case WAND
J. Ala-Laurila (Nokia, Finland)
2- On some issues in Wireless ATM
M. Gagnaire (ENST, France)
3- ATM as transport technology in Mobile systems
H. Eriksson (Ericsson, Sweden)
12:30 pm
Lunch
14:00 pm
Track 7 : Services in Wireless and Mobile Networks
Chairman : G. Omidyar (Illinois Institute of Technology
Research Institute)
1- Issues in the survivability of wireless mobile networks
T. A. Dahlberg, (University of North Carolina at Charlotte, USA)
S. Ramaswamy and D. Tipper, (University of Pittsburgh, USA)
2- UPT Services and the Intelligent Network
R. Nevoux (CNET France T=E9l=E9com, France)
3- Towards Intelligent Management of Mobile Cellular Networks
R. Boutaba (CRIM, Canada)
15 :30 pm
Break
16:00 pm
Track 8 : Ressource Management
Chairman : V. Veque (LRI, University of Paris Sud, France)
1- Congestion problem due to handover traffic
X. Lagrange (ENST, France)
2- Comparison of Different Handover Policies for Joint Voice-Data
Cellular Networks
D. Calin and D. Zeghlache. (INT, France)
3- PRP : A New Policy with Channel Reservation and Prediction in
Cellular Communication Systems
S. Boumerdassi, G. Pujolle (PRiSM, University of Versailles, France)
_________________________________________________________________
REGISTRATION
CHARGES
The registration fee :
1400 FF for IFIP, IEEE and ACM members
1800 FF for non IFIP, IEEE and ACM members
(includes proceedings, coffee breaks, and one dinner/reception).
Tutorial fees are 500 FF for half a day and 1000 FF for a full day.
TOTAL PAYMENT: _____________________
Method of payment (delete as not applicable):
PAID BY Check (enclosed, payable to DNAC)
or
PAID BY Credit card (details below)
_________________________________________________________________
CREDIT CARD DETAILS
Visa card and Master card
No. ________ ________ ________ ________
Expiry date ____ / ____
I authorize you to charge the sum of ______________ to my credit card
numbered as above
Signature ________________
Date ________________
_______________________________________________________________
YOUR DETAILS
Name _____________________________________________
Position (or job title) _____________________________________________
Affiliation _____________________________________________
Address _____________________________________________
_____________________________________________
_____________________________________________
Country _____________________________________________
Phone # _____________________________________________
FAX # _____________________________________________
E-mail _____________________________________________
__________________________________________________________________________=
__
SEND THIS FORM
by post with check or credit card payment to:
Guy Pujolle
PRiSM, University of Versailles
45 av. des Etats-Unis
78000 Versailles, France
FAX: (33) 1 39 25 40 57,
e-mail: mwcn at prism.uvsq.fr
__________________________________________________________________
__________________________________________________________________
You can choose your hotel and make reservation.
The Workshop will take place in "La Sorbonne" and the "arrondissements"
of Paris corresponding to the location are 5th and 6th arrondissement
(Quartier Latin). A list of hotels situated near "La Sorbonne" is as
follows (from the best to the more economical ; from **** to * stars):
----------------------- **** ----------------------
RIVES DE NOTRE DAME (Les)
15, quai Saint Michel; 75005 PARIS
Metro Saint Michel
RER Saint Michel - Notre Dame
phone : (331)43.54.81.16
fax : (331)43.26.27.09
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1879
RELAIS CHRISTINE
3, rue Christine; 75006 PARIS
Metro Od=E9on
RER Saint Michel - Notre Dame
phone : (331)43.26.71.80
fax : (331)43.26.89.38
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1983
----------------------- *** -----------------------
CALIFORNIA
32, rue des Ecoles; 75005 PARIS
Metro Maubert Mutualit=E9
RER Saint Michel - Notre Dame
phone : (331)46.34.12.90
fax : (331)46.34.75.52
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1883
GRANDS HOMMES (Des)
17, place du Panth=E9on; 75005 PARIS
Metro Maubert Mutualit=E9
RER Luxembourg
phone (331)46.34.19.60
fax (331)43.26.67.32
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1889
---------------------- ** --------------------------
CLUNY SORBONNE
8, rue Victor Cousin; 75005 PARIS
Metro Cluny - Sorbonne
RER Luxembourg
Phone : (331)43.54.66.66
fax : (331)43.29.68.07
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1914
SAINT SEVERIN
40, rue Saint-S=E9verin; 75005 PARIS
Metro Saint Michel
RER Saint Michel - Notre Dame
phone : (331)46.34.05.70
fax : (331)46.33.84.47
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1936
------------------------ * --------------------------
EXCELSIOR
20 Rue Cujas; 75005 PARIS
Metro Luxembourg
RER Luxembourg
phone : (331)46.34.79.50
fax : (331)43.54.87.10
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1950
14, rue de la Sorbonne; 75005 PARIS
Metro Cluny - Sorbonne
RER Luxembourg
phone : (331)43.54.28.40
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1953
--------------------------------------------------
Received: from ietf.org by ietf.org id aa11945; 20 Apr 97 16:15 EDT
Received: from cnri by ietf.org id aa11726; 20 Apr 97 16:04 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa26771;
20 Apr 97 16:04 EDT
Received: from dworkin.wustl.edu by venera.isi.edu (5.65c/5.61+local-26)
id <AA01706>; Sun, 20 Apr 1997 13:01:00 -0700
Received: (from milind at localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA27378 for ietf at venera.isi.edu; Sun, 20 Apr 1997 15:03:32 -0500
Date: Sun, 20 Apr 1997 15:03:32 -0500
Sender:ietf-request at ietf.org
From: "Milind M. Buddhikot" <milind at dworkin.wustl.edu>
Message-Id: <199704202003.PAA27378 at dworkin.wustl.edu>
To: ietf at isi.edu
Subject: NOSSDAV97 Advance Program + Registration Announcement
Source-Info: From (or Sender) name not authenticated.
The 7th International Workshop on
Network and Operating System Support for Digital Audio and Video
NOSSDAV'97
St. Louis, Missouri, USA
May 19-21, 1997
Registrations for NOSSDAV'97 are now being accepted.
The 7th International Workshop on Network and Operating Systems Support
for Digital Audio and Video (NOSSDAV 97) is the international workshop
concerned with state of the art technology in networking and operating
system support for multimedia systems. For seven years, NOSSDAV has
proven to be an outstanding forum for researchers involved in building
innovative multimedia systems, networks and applications on both the
research and industrial front. Other topics that will be examined include
"middleware" for multimedia, media toolkits, mobile communications,
Virtual Reality (VR), real-time systems, software agents, digital libraries,
and other digital media besides audio and video.
A key aspect of the workshop is that it provides extensive discussion
periods during which attendees can informally discuss their current
work and future research directions. Traditionally, NOSSDAV has
emphasized on high quality experimental research that prototypes
systems to explore innovative solutions to the problems in the diverse
areas of multimedia computing. NOSSDAV97 will continue this tradition.
A sample of the sessions to be held at the workshop include:
Multicast for Multimedia
Networking: Packet Scheduling and Integrated Services
Multimedia-on-Demand (MOD) Servers and Services
Smoothing and Scaling on Endsystems
Mobility and Wireless
Operating System Optimizations
Middleware for Multimedia
To maintain the atmosphere of a small intense workshop, attendance is
once again being limited to 80.
Spots at the workshop are being reserved for one author per paper and
Program Committee members until April 10th. All other registration requests
will be accepted on a first come first served basis. After April 10th any
other requests that previously could not be immediately accepted will be
confirmed if space is available.
Presenting Authors and PC Members should register as soon as possible!!
On line registration and workshop program information can be accessed
from the NOSSDAV97 web page:
http://www.arl.wustl.edu/arl/NOSSDAV97/
The workshop will be held at Innsbrook Estates. Located approximately 45
minutes from the St. Louis airport, Innsbrook Estates has everything you
would like in a resort: 18-hole golf course, 18-hole miniature
course, swimming pool, a 150 acre lake, sailing, fishing,
swimming, sand beaches, fitness center, lighted tennis courts,
volleyball courts, horse back riding, full conference facilities, etc.
Send inquiries to:
NOSSDAV97 at arl.wustl.edu
ATTN: NOSSDAV97
Department of Computer Science/ARL
Campus Box 1045
Washington University
One Brookings Drive
St. Louis MO 63130, USA
Tele: 1 314 935 7534
Fax: 1 314 935 7302
NOSSDAV '97
Schedule
Sunday, May 18, 1997
16:00-19:00 Conference Registration
19:00-21:30 Informal Dinner ???
Monday, May 19, 1997
7:30-8:30 Breakfast Buffet
8:30-9:00 Introductions and Welcome
Christopher I. Byrnes
Dean of the School of Engineering and Applied
Science
Washington University
Workshop Chairs
Guru Parulkar
John DeHart
9:00-10:30 Session I "Multimedia-on-Demand (MOD) Servers and Services"
Session Chair: Derek McAuley, Univ of Glasgow, UK
* Design and Implementation of Video Server for Mixed-rate
Streams
J. Nishikawa, I. Okabayashi, Y. Mori, S. Sasaki, M.
Migita, Y. Obayashi, S. Furuya and K. Kaneko.
Matsushita Electric Industrial Co.
* Random RAIDs with Selective Exploitation of Redundancy
for High Performance Video Servers
Y. Birk. Technion - Israel Inst. of Technology.
* Efficient Striping Techniques for Multimedia File Servers
P. Shenoy, and H. Vin. University of Texas.
10:30-11:00 Break
11:00-12:30 Session II "Middleware for Multimedia Applications"
Session Chair: Steve McCanne
* Toward a Common Infrastructure for
Multimedia-Networking Middleware
S. McCanne et al,
University of California,Berkeley
* An Extensible Framework for RTP-based Multimedia
Applications
John Du, Dave Putzolu, Intel Corporation
* Network Filters for Active Movie
Mike Clark, Thomas Pfenning, Microsoft
12:30-13:30 Lunch
13:30-15:00 Session III "Networking"
Session Chair: KK Ramakrishnan, AT&T Research
* A Comprehensive Multimedia Control Architecture for the
Internet
H. Schulzrinne. Columbia University.
* Environments for Active Networks
R. Sharma, S. Keshav, M. Wu and L. Wu. Cornell
Univeristy.
* WANDS: Wide-Area Network Delay Simulator
M. Borella & A. Sears. DePaul University.
SHORT PAPER:
* A Virtual Network Service for Integrated-Services
Internetworks
L. Delgrossi and Domenico Ferrari. Unversita
Cattolica.
15:00-15:30 Break
15:30-17:00 Session IV "Operating System Optimizations"
Session Chair: Hide Tokuda, Keio Univ, Japan
* Evaluation of Data Passing and Scheduling Avoidance
J. Brustoloni and P. Steenkiste. Carnegie Mellon
University.
* User-Safe Devices for True End-to-End QoS
I. Pratt. University of Cambridge.
* A Fresh Approach to File System Quality of Service
P. Barham. University of Cambridge.
17:00-18:00 Break
18:00-20:00 Banquet
20:00-21:00 PC/Planning Meeting
Tuesday, May 20, 1997
7:30-8:30 Breakfast Buffet
8:30-10:00 Session V "Mobility and Wireless"
Session Chair: Doug Shepherd, University of Lancaster, UK
* Mobile Filters: Delivering Scaled Media to Mobile Devices
A. Balachandran and A. Campbell
* System Support for Mobile Multimedia Applications
Inouye, Cen, Walpole
* On Quality of Service in Mobile Wireless Networks
M. Srivastava, P. Mishra
10:00-10:30 Break
10:30-12:00 Session VI "Multicast"
Session Chair: Dan Swinehart, Xerox PARC
* Layered Video Multicast with Retransmission (LVRM):
Evaluation of Error Recovery Schemes
X. Li and M. Ammar. Georgia Institute of Technology.
S. Paul and P. Pancha. Bell Laboratories.
* Thin Streams: An Architecture for Multicasting Layered
Video
L. Wu, R. Sharma and B. Smith. Cornell University.
* Resilient Multicast Support for Continuous Media
Applications
R. Xu, A. Myers, H. Zhang, R. Yavatkar. Carnegie
Mellon University and Intel.
12:00-13:00 Lunch
13:00-15:00 Session VII "Short Papers and A Lang Panel Session:
Traffic Management"
Session Chair: Domenico Ferrari, Universita` Cattolica, Italy
* Service Aggregation Through Rate Adaptation Using a
Single Storage Format
Krishnan and Little
* Practical Experience with a Smoothing Algorithm for Video
Streaming
F. Miller, X. Mei, T. Lam, K. Zhang, and S.
Tripathi. University of Maryland.
* Randomized Token Buckets: Reducing the Buffers Required
in Multiplexors
J. A. Fingerhut and G. Varghese. Washington
University.
15:00-16:30 Break
16:30-23:59 Excursion (To Cardinals Baseball Game)
Wednesday, May 21, 1997
8:00-9:00 Breakfast Buffet
9:00-10:30 Session VIII "Smoothing, Scaling, etc on Endsystems"
Session Chair: TBD
* The Performance of Two Dimensional Media Scaling for
Internet Videoconferencing: Experiments with ProShare(TM)
on the Internet
P. Nee, K. Jeffay and G. Danneels. University of
North Carolina.
* Online Smoothing of Live, Variable-Bit-Rate Video
J. Rexford. AT&T Research Laboratories.
S. Sen, K. Dey, J. Kurose, J. Stankovic, D. Towsley.
University of Massachusetts.
W. Feng. Ohio State University.
* Adaptive Middleware for Mobile Multimedia Applications
G. Blair, G. Coulson, N. Davies, P. Robin and T.
Fitzpatrick.Lancaster University.
10:30-11:00 Break
11:00-12:30 Session IX "Networking: Packet Scheduling, Integrated Service"
Session Chair: Hui Zhang, CMU
* Fair Airport Scheduling Algorithms
P. Goyal and H. Vin. University of Texas.
* Hierarchical Relative Error Scheduler: An Efficient
Traffic Shaper for Packet Switching Networks
A. Charny. Digital Electric Company.
* Understanding TCP Dynamics in an Integrated Services
Internet
W. Feng, D. Kandlur, D. Saha and K. Shin. IBM.
12:30-13:30 Lunch
Workshop ends
----------------------------------------------------------------------------
nossdav97 at arl.wustl.edu
Received: from cnri by ietf.org id aa13582; 20 Apr 97 17:36 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21312;
20 Apr 97 17:36 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <UAA12761 at pad-thai.cam.ov.com>; Sun, 20 Apr 1997 20:07:28 GMT
Date: Sun, 20 Apr 1997 16:07:15 -0400 (EDT)
From: Srikanth N Sridhara <nanja_s at cs.odu.edu>
To: cat-ietf at mit.edu
Subject: Unsubscribe
Message-Id: <Pine.SOL.3.95.970420160639.3191B-100000 at blizzard.cs.odu.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk
unsubscribe nanja_s at cs.odu.edu
Received: from cnri by ietf.org id aa27418; 21 Apr 97 2:32 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22048;
21 Apr 97 2:32 EDT
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <FAA01102 at pad-thai.cam.ov.com>; Mon, 21 Apr 1997 05:10:16 GMT
From: bengt.ackzell at generic.se
Message-Id: <199704210510.HAA23468 at mail.swip.net>
Date: Mon, 21 Apr 1997 7:03:04 +0100
To: cat-ietf at mit.edu
Subject: Svar: I-D ACTION:draft-ietf-cat-idup-cbind-03.txt
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailer: TFS Gateway /220000000/220680038/220660038/220750038/
Precedence: bulk
In the internet draft action, in the introduction of the IDUP=20
C-bindings (draft-ietf-cat-idup-cbind-03.txt), it still refers to=20
RFC-1508.=20
IDUP do extends the GSS-API ver.2 RFC-2078.
=20
/Bengt Ackzell
Received: from ietf.org by ietf.org id aa04081; 21 Apr 97 9:29 EDT
Received: from rx7.ee.lbl.gov by ietf.org id aa03533; 21 Apr 97 9:18 EDT
Received: by rx7.ee.lbl.gov (8.8.2/1.43r)
id GAA17356; Mon, 21 Apr 1997 06:19:17 -0700 (PDT)
Message-Id: <199704211319.GAA17356 at rx7.ee.lbl.gov>
To: ietf at ietf.org
cc: rem-conf at es.net
Subject: pathchar - a new tool for characterizing Internet paths
Date: Mon, 21 Apr 97 06:19:16 PDT
Sender:ietf-request at ietf.org
From: Van Jacobson <van at ee.lbl.gov>
Source-Info: From (or Sender) name not authenticated.
For the past 6 years, I've been working on a tool to figure out
more about an Internet path that just what routers you go through.
I've developed a tool called `pathchar' (for `path characteristics')
that tells you the bandwidth, distance from previous hop, average
queue, and drop rate for every hop on the path (*not* just the
bottleneck hop). This is a typical output:
% pathchar ka9q.ampr.org
mtu limitted to 1500 bytes at local host
doing 32 probes at each of 64 to 1500 by 32
0 localhost
| 8.7 Mb/s, 292 us (1.97 ms)
1 ir40gw.lbl.gov (131.243.1.1)
| 29 Mb/s, 132 us (2.64 ms)
2 er1gw.lbl.gov (131.243.128.11)
| 91 Mb/s, 189 us (3.15 ms)
3 lbl-lc1-1.es.net (198.128.16.11)
| 25 Mb/s, 6.92 ms (17.5 ms)
4 gac-atms.es.net (134.55.24.6)
| 11 Mb/s, 424 us (19.4 ms)
5 CERFNETGWY.GAT.COM (192.73.7.163)
| 7.0 Mb/s, 1.20 ms (23.5 ms)
6 sdsc-ga.cerf.net (134.24.20.15)
| ?? b/s, -263 us (22.8 ms)
7 mobydick-fddi.cerf.net (134.24.252.3)
| 46 Mb/s, -51 us (22.9 ms)
8 qualcomm-sdsc-ds3.cerf.net (134.24.47.200)
| 9.0 Mb/s, 17 us (24.3 ms)
9 krypton-e2.qualcomm.com (192.35.156.2)
| 5.5 Mb/s, 1.04 ms (28.6 ms)
10 ascend-max.qualcomm.com (129.46.54.31)
| 56.7 Kb/s, 6.19 ms (253 ms)
11 karnp50.qualcomm.com (129.46.90.33)
| 10 Mb/s, -50 us (253 ms), +q 3.32 ms (6.58 KB) *2
12 unix.ka9q.ampr.org (129.46.90.35)
rtt 32 ms (253 ms), bottleneck 56.7 Kb/s, pipe 4706 bytes
The lines starting with `|' are the characteristics of the link
between the hops listed above & below. The first number is the
link bandwidth, the 2nd is the one-way prop time (i.e., for a
zero length packet) & the number in parens is the round trip
time you would get if there were no queues and you sent a
path-mtu sized packet from the source to this hop (i.e., the
unloaded data rtt). If there's a queue larger than 1 packet,
its size in both time & bytes is printed. If the drop rate is
more than 1%, it's printed.
Note that it successfully found the LBL FDDI dmz (hops 2-3) &
SDSC-Qualcomm T3 (hops 7-8) even though I was running it behind
a 10Mb/s ethernet. And that the long hop from San Francisco to
San Diego is clearly visible (3-4). (Also note that I was
running this at 1am this morning so the normal cerfnet queues
were missing & only Phil's P50 ISDN box showed a queue.)
We're hoping to release pathchar sometime in the next two weeks.
I'm giving a talk on it today at 4pm PDT for MSRI Math Awareness
Week and the talk should be mboned. I've put the viewgraphs
from the talk (which are the only existing documentation) at
ftp://ftp.ee.lbl.gov/pathchar/msri-talk.ps.gz
If you really deperately want to play with a very flakey, alpha
version of pathchar, there are binaries for freebsd, linux and
solaris in the same directory (but you are totally on your own
when running this -- we'll answer questions once the beta release
goes out but right now we're putting all our energy into getting
it out).
Cheers.
- Van
Received: from ietf.org by ietf.org id aa05075; 21 Apr 97 9:46 EDT
Received: from ietf.ietf.org by ietf.org id aa04660; 21 Apr 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-touch-tcp-interdep-01.txt
Date: Mon, 21 Apr 1997 09:42:54 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704210942.aa04660 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : TCP Control Block Interdependence
Author(s) : J. Touch
Filename : draft-touch-tcp-interdep-01.txt
Pages : 11
Date : 04/18/1997
This draft makes the case for interdependent TCP control blocks, where part
of the TCP state is shared among similar concurrent connections, or across
similar connection instances. TCP state includes a combination of
parameters, such as connection state, current round-trip time estimates,
congestion control information, and process information. This state is
currently maintained on a per-connection basis in the TCP control block,
but should be shared across connections to the same host. The goal is to
improve transient transport performance, while maintaining
backward-compatibility with existing implementations.
This document is a product of the LSAM project at ISI. Comments are
solicited and should be addressed to the author.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-touch-tcp-interdep-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-touch-tcp-interdep-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-touch-tcp-interdep-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: <19970418175642.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-touch-tcp-interdep-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-touch-tcp-interdep-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970418175642.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05080; 21 Apr 97 9:46 EDT
Received: from ietf.ietf.org by ietf.org id aa04616; 21 Apr 97 9:42 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-hierarchy-00.txt
Date: Mon, 21 Apr 1997 09:42:51 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704210942.aa04616 at ietf.org>
--NextPart
Note: This announcement is being re-sent with a corrected filename.
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 : Hierarchical Extensions to the Common Indexing Protocol
Author(s) : C. Weider, P. Leach
Filename : draft-ietf-find-cip-hierarchy-00.txt
Pages : 15
Date : 04/18/1997
This work explores what, in the parlance of the current CIP draft, is
called an index type -- specifically, a new kind of index that merges
indexing of hierarchically named attribute-value entities (such as in LDAP
and RWHOIS) and ones without distinguished names (such as in WHOIS++). It
is based on a previous version of the CIP specification, but that was just
a convenient syntactical jumping off point. It is intended to be orthogonal
to the FIND working group task of defining a framing syntax and
functionality for a common indexing data wrapping protocol, and that the
concepts and protocol elements in this draft should be able to be expressed
in a manner consistent with the new CIP framework at the appropriate time.
Internet-Drafts are available by anonymous FTP. 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-hierarchy-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-find-cip-hierarchy-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-hierarchy-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: <19970418175327.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-find-cip-hierarchy-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-find-cip-hierarchy-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970418175327.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05085; 21 Apr 97 9:46 EDT
Received: from ietf.ietf.org by ietf.org id aa04502; 21 Apr 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-showalter-sieve-00.txt
Date: Mon, 21 Apr 1997 09:42:37 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704210942.aa04502 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : SIEVE: A Mail Filtering Language
Author(s) : T. Showalter
Filename : draft-showalter-sieve-00.txt
Pages : 19
Date : 04/18/1997
This document describes a mail filtering language for filtering messages at
time of final delivery. It is designed to be independent of protocol, and
implementable on either a mail client or mail server which uses multiple
folders. It is meant to be extensible, simple, and independent of access
protocol, mail architecture, and operating systems used to implement it.
Mail filtering systems are widely used for a variety of reasons, including
organization of messages (filtering out mailing list messages for separate
reading). They are becoming increasingly useful in avoiding unsolicited
mail. Existing languages are not consistant across client, server, or
operating system, and are frequently difficult for users to use. This
language is not tied to any particular system or mail architecture and is
suitable for running on a mail server where users may not be allowed to
execute arbitrary programs, such as on black box IMAP 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-showalter-sieve-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-showalter-sieve-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-showalter-sieve-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: <19970418100553.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-showalter-sieve-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-showalter-sieve-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970418100553.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05081; 21 Apr 97 9:46 EDT
Received: from ietf.ietf.org by ietf.org id aa04585; 21 Apr 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-ema-vpim-05.txt
Date: Mon, 21 Apr 1997 09:42:47 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704210942.aa04585 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Voice Profile for Internet Mail - version 2
Author(s) : G. Vaudreuil, G. Parsons
Filename : draft-ema-vpim-05.txt
Pages : 44
Date : 04/18/1997
A class of special-purpose computers has evolved to provide voice messaging
services. These machines generally interface to a telephone switch and
provide call answering and voice messaging services. Traditionally,
messages sent to a non-local machine are transported using analog
networking protocols based on DTMF signaling and analog voice playback. As
the demand for networking increases, there is a need for a standard
high-quality digital protocol to connect these machines. The following
document is a profile of the Internet standard MIME and ESMTP protocols for
use as a digital voice messaging networking protocol. The profile is
referred to as VPIM (Voice Profile for Internet Mail) in this document.
This profile is based on earlier work in the Audio Message Interchange
Specification (AMIS) group that defined a voice messaging protocol based on
X.400 technology. This profile is intended to satisfy the user
requirements statement from that earlier work with the industry standard
ESMTP/MIME mail protocol infrastructures already used within corporate
intranets. This second version of VPIM is based on implementation
experience and obsoletes RFC 1911 which describes
version 1 of the profile.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ema-vpim-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ema-vpim-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-ema-vpim-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: <19970418174733.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ema-vpim-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ema-vpim-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970418174733.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05082; 21 Apr 97 9:46 EDT
Received: from ietf.ietf.org by ietf.org id aa04545; 21 Apr 97 9:42 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-ds-bcp-03.txt
Date: Mon, 21 Apr 1997 09:42:45 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704210942.aa04545 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 : Best Current Practice for the Internet White Pages
Service
Author(s) : H. Alvestrand, P. Jurg
Filename : draft-ietf-ids-ds-bcp-03.txt
Pages : 17
Date : 04/18/1997
The Internet is used for information exchange and communication between its
users. It can only be effective as such if users are able to find each
other's addresses. Therefore the Internet benefits from an adequate White
Pages Service, i.e., a directory service offering (Internet) address
information related to people and organizations.
Internet-Drafts are available by anonymous FTP. 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-ds-bcp-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ids-ds-bcp-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-ids-ds-bcp-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: <19970418173727.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ids-ds-bcp-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ids-ds-bcp-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970418173727.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05528; 21 Apr 97 9:52 EDT
Received: from ietf.ietf.org by ietf.org id aa05386; 21 Apr 97 9: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-rfced-info-ruffen-00.txt
Date: Mon, 21 Apr 1997 09:50:11 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704210950.aa05386 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : SBCD Protocol Specification
Author(s) : K. Dobbins, T. Grant, D. Ruffen
Filename : draft-rfced-info-ruffen-00.txt
Pages : 7
Date : 04/16/1997
The Switch Broadcast Control and Delivery (SBCD) protocol is part of the
InterSwitch Message Protocol (ISMP). ISMP was designed to facilitate
interswitch communication within distributed connection-oriented switching
networks. The SBCD protocol is used to reduce the amount of broadcast
traffic across the switch fabric by restricting unresolved broadcast
packets to only those ports that belong to the same VLAN as the source.
Internet-Drafts are available by anonymous FTP. 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-ruffen-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-ruffen-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-ruffen-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: <19970416161259.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-ruffen-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-ruffen-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970416161259.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05968; 21 Apr 97 9:57 EDT
Received: from ietf.ietf.org by ietf.org id aa05776; 21 Apr 97 9:54 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-atmarp-00.txt
Date: Mon, 21 Apr 1997 09:54:27 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9704210954.aa05776 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internetworking Over NBMA
Working Group of the IETF.
Title : A Distributed ATMARP Service Using SCSP
Author(s) : J. Luciani, B. Fox
Filename : draft-ietf-ion-scsp-atmarp-00.txt
Pages : 6
Date : 04/16/1997
This document describes a method for distributing an ATMARP service within
a LIS[1]. This method uses the Server Cache Synchronization Protocol
(SCSP)[2] to synchronize the ATMARP server databases within a LIS. When
SCSP is used to synchronize the caches of ATMARP servers in a LIS, the LIS
defines the boundary of an SCSP Server Group (SG).
Internet-Drafts are available by anonymous FTP. 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-atmarp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-scsp-atmarp-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-ion-scsp-atmarp-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: <19970416105249.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-scsp-atmarp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-scsp-atmarp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970416105249.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12097; 21 Apr 97 11:20 EDT
Received: from spinoza.terena.nl by ietf.org id aa11960; 21 Apr 97 11:17 EDT
Received: from [192.87.30.51] (PaulsMac.terena.nl [192.87.30.51]) by spinoza.terena.nl (8.7.6/8.7.3) with SMTP id RAA20257; Mon, 21 Apr 1997 17:13:48 +0200 (MET DST)
X-Sender: paul at popper.terena.nl
Message-Id: <v02140b0aaf8124db6eda at [192.87.30.51]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 21 Apr 1997 16:18:52 +0200
To: terena-ga at terena.nl, wg-all at terena.nl, newsletters at terena.nl,
ceec at terena.nl, ietf at ietf.org, ccirn at fnc.gov, apng-all at apng.org,
jenc8-info at terena.nl, press at terena.nl, lhl at cs.wisc.edu, tf-atm at terena.nl,
tf-cache at terena.nl, tf-chic at terena.nl, tf-etinu at terena.nl,
tf-etm at terena.nl, tf-local at terena.nl, tf-ten at terena.nl,
tf-tooldoc at terena.nl
Sender:ietf-request at ietf.org
From: Paul Rendek <paul at terena.nl>
Subject: JENC8 "Final Programme", May 12-15, 1997, Edinburgh, Scotland
Source-Info: From (or Sender) name not authenticated.
"8th Joint European Networking Conference" (JENC8)
Edinburgh, Scotland, 12-15 May 1997
The JENC8 "FINAL PROGRAMME" and registration information is now available
via the Web. Please visit the JENC8 conference Web site for further
information at:
http://www.terena.nl/jenc8/
For conference registration enquiries please send an email to <jenc8 at ed.ac.uk>
For general enquiries please send an email to <jenc8-sec at TERENA.nl>
or contact:
TERENA Secretariat
Singel 466-468
NL - 1017 AW Amsterdam
The Netherlands
Tel: +31 20 639 1131
Fax: +31 20 639 3289
Email: jenc8-sec at TERENA.nl
Received: from ietf.org by ietf.org id aa15358; 21 Apr 97 12:27 EDT
Received: from cheerios.cisco.com by ietf.org id aa15125; 21 Apr 97 12:19 EDT
Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id JAA18186 for <ietf at ietf.org>; Mon, 21 Apr 1997 09:16:11 -0700
X-Sender: deering at cheerios.cisco.com
Message-Id: <v03020902af8140e5a122 at [171.69.116.90]>
In-Reply-To: <199704161242.OAA07246 at arrakis.es>
References: <9704152016.AA04842 at katahdin.columbia.sparta.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 21 Apr 1997 09:16:35 -0700
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Steve Deering <deering at cisco.com>
Subject: Re: Hotel space in Munich
Source-Info: From (or Sender) name not authenticated.
FYI, the IETF block of rooms at the Sheriton Munich is already exhausted for
Aug 13 and 14 -- I got put on a waiting list for those two days. That'll
teach me to wait a whole 5 days after the hotel announcement message to make
my reservation. This has become like one of those radio call-in contests:
"The first 300 lucky callers will win a reservation at the World Famous
Sheraton Hotel in Magnificent Munich!!" I wonder how long it will be before
we read of a phone system meltdown triggered by an IETF At-A-Glance posting?
Steve
Received: from ietf.org by ietf.org id aa16035; 21 Apr 97 12:40 EDT
Received: from faui40.informatik.uni-erlangen.de by ietf.org id aa15882;
21 Apr 97 12:36 EDT
Received: from faui45r.informatik.uni-erlangen.de (eckert at faui45r.informatik.uni-erlangen.de [131.188.2.54])
by faui40.informatik.uni-erlangen.de (8.8.5/8.0.5-FAU) with ESMTP id SAA21545; Mon, 21 Apr 1997 18:32:53 +0200 (MET DST)
Sender:ietf-request at ietf.org
From: Toerless Eckert <Toerless.Eckert at informatik.uni-erlangen.de>
Message-Id: <199704211632.SAA21545 at faui40.informatik.uni-erlangen.de>
Subject: Re: Hotel space in Munich
To: Steve Deering <deering at cisco.com>
Date: Mon, 21 Apr 1997 18:32:50 +0200 (MET DST)
Cc: ietf at ietf.org
In-Reply-To: <v03020902af8140e5a122 at [171.69.116.90]> from "Steve Deering" at Apr 21, 97 09:16:35 am
Organisation: CSD IMMD IV, University of Erlangen, Germany
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
> "The first 300 lucky callers will win a reservation at the World Famous
> Sheraton Hotel in Magnificent Munich!!" I wonder how long it will be before
> we read of a phone system meltdown triggered by an IETF At-A-Glance posting?
What kind of phone system meltdown are you looking for ? I guess the
kind we had at the Dallas IETF depends very much on the sponsor.
Received: from ietf.org by ietf.org id aa16278; 21 Apr 97 12:43 EDT
Received: from nausicaa.mew.com by ietf.org id aa16169; 21 Apr 97 12:41 EDT
Received: from yupa.ca.mew.com (yupa.ca.mew.com [158.118.11.11]) by nausicaa.mew.com (8.6.11+2.5Wb2/3.4W-Claude-NAUSICAA-961123) with ESMTP id JAA00725; Mon, 21 Apr 1997 09:35:03 -0700
Received: from kiki.ca.mew.com (kiki.ca.mew.com [158.118.11.12]) by yupa.ca.mew.com (8.6.11+2.5Wb2/3.4W-YUPA-950728) with SMTP id JAA01482; Mon, 21 Apr 1997 09:36:54 -0700
Sender:ietf-request at ietf.org
From: Claude Huss <claude at ca.mew.com>
Message-Id: <199704211636.JAA01482 at yupa.ca.mew.com>
Subject: Re: Hotel space in Munich
To: Steve Deering <deering at cisco.com>
Date: Mon, 21 Apr 1997 09:35:48 -0700 (PDT)
Cc: ietf at ietf.org
In-Reply-To: <v03020902af8140e5a122 at [171.69.116.90]> from "Steve Deering" at Apr 21, 97 09:16:35 am
X-Disclaimer: Opinions expressed here are strictly my own
Organization: Matsushita Electric Works, Ltd.
X-Mailer: ELM [2.4 PL23.Japanese] (Claude Huss)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1031
Source-Info: From (or Sender) name not authenticated.
You dont need to go very far. I tried to book a hotel for Interop Las
Vegas and I called just at the morning of the first day the company
handling housing for Interop started to accept applications. All the
best hotels were gone already! They said to me that as soon as midnight,
they started to receive thousands of reservations through fax...
I am not going to be surprised, if next IETF in the US is going to happen
the same.
Claude
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.
